[Bf-committers] Viewport FX Design

Brecht Van Lommel brechtvanlommel at pandora.be
Fri Jun 1 21:00:44 CEST 2012

On Fri, Jun 1, 2012 at 8:02 PM, Jason Wilkins <jason.a.wilkins at gmail.com> 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

> 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.


More information about the Bf-committers mailing list