On Fri, Jun 1, 2012 at 8:02 PM, Jason Wilkins <[email protected]> wrote: >> Basically the API will always be, allocate an array for each needed >> attribute, fill up the arrays, and then give them back. > > Give them back? I'm not sure what you mean. We must assume that if > the client code has a pointer to the buffer then that buffer cannot be > drawn.
I just meant release / free the arrays, or whatever the API needs to do depending if it's using VBO's, vertex arrays, immediate/retained, ... . > Also, and most importantly, doing it the way you suggest requires that > the programmer re-specify colors and normals for every vertex instead > of relying on the cached copy to be there. This is significantly > different than how OpenGL has worked. It's a different yes, but just a small modification I think. Regarding performance, note that can depend a lot on the GPU, drivers and the type of mesh used. If your GPU is significantly faster than the CPU, it matters more. At least on recent GPU's I tested basic viewport performance has not improved much because the CPU was the bottleneck. It just seems a bit overkill to have 7 conditionals per vertex when really all that needs to happen is just copying some data into an array. > I have two other justifications that could be thrown out the window. > > 1) It keeps the code simple and safe. No checks that you used > TexCoord3 when you said there were only 2 texcoords. This does not seem like a good reason to me, if they are mismatched I'd rather have it throw me an error. > 2) I was entertaining the idea of using write combined memory for the > buffer (NV_vertex_array_range), and such a buffer needs to be written > sequentially. This point I don't understand. But anyways, if the performance is not affected I don't care that much, and it can still be optimized afterwards if it turns out to be a bottleneck, would not affect the design really. > Right now I have a set of functions that combine common vertex format > specifications with locking in the format. Since there are so few > actual formats I figured I could just make them inline and not bother > with the logic to implement bit flags. But its obviously just a style > choice. > > My utility functions have names like: gpuImmediateFormat_C4_N3_V3(); > > And one command to end it, gpuImmediateUnformat(); Ok, that can work as well. > It is legal to nest these commands, but the format isn't changed. > This is another reason why I cache the current vertex instead of > copying it directly into the array, it allows for code with compatible > formats to be nested like this without worrying about firing an > assertion or having to add checks to the glCurrentX functions. I don't think nesting should be allowed? I imagine any code using these should keep them near the associated gpuBegin/gpuEnd to keep things from getting out of sync. > If you want to use flags/enums, why not just use something like OpenGL > 1.2's interleaved array formats? Again though, it isn't incredibly > important so long as its easy to read and use. Mainly I want something that is more clear than the example usage that is in e.g. blenfont, found that difficult to read. With something like GPU_TEX_COORD_3F it's immediately clear that this matches gpuTexCoord3f. But if it's abbreviated that's also fine with me. Anyways, overall I agree with your plans then. Brecht. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
