Real-time mesh editors with VBOs

Are VBOs appropriate for real-time mesh editing (i.e. using a mouse to move a vertex/face and have the mesh update) ? If so, are their use for real-time editing considered best current-day OpenGL practice?

I ask because I’d like attempt to make a basic modeling program with out immediate mode OpenGL commands. Also, since OpenGL ES and 3 (maybe?) look to cut out immediate mode or deprecate it, I thought it would be an interesing challenge.

If your data changes often, the VBOs may loose their speed advantage. Hovewer, you can “edit” vertices via buffer mapping. So, this shoudl be pretty easy. You will probably want to use STREAM_DRAW flag for the buffer

Mesh editors often render way more times than it updates the mesh, and in this case it’s definitly an performance increase.
But i have also noticed that under certain conditions updating the entire VBO for each frame is often faster than using immediate mode, probably mostly becasue no driver preprocessing is done on VBO data.

Thank you for your replies Zengar and zeoverlord.

Zengar, when you say VBOs might loose their speed advantage, is that in comparison to immediate mode or something like display lists or vertex arrays?

In comparison to VBOs that are not updated very often ))


I guess I really meant to ask was: when they lose their speed advantage, would they still perform better than things like display lists or vertex arrays?

No idea. It depends on the driver and the situation. But, immediate mode and display lists are out of question (first because they are slow, second because the geometry changes); and there is no way VBOs could be slower then usual client-side arrays — if it happens, driver developers must have screwed really bad.

True, immediate mode is only really viable today when your dealing with a few single polygons, like full screen polygons, mouse pointer or maybe some hud elements.
And while display lists may be slightly faster they are significantly slower than VBO and less dynamic than immediate mode

Here is what Michael Gold answered to a similar question. (Afaik he is or was ARB member before the silence started.)


Oh, it can easily happen. E.g. use separate VBOs for each vertex attribute, don’t interleave, use vertex formats which are “non-optimal” (a heretofore unspecified list), and use lots of tiny batches.

I don’t know if the the driver is pushing the data back to the CPU, converting it, and re-pushing it to the GPU every frame or what, but a quick, simple minded application of VBOs can double your frame time (halve your frame rate).

However, spending a little time with VBOs can get you some very nice performance increases over client arrays. Not as much as with display lists, but a good portion of that.

The driver is much more tolerant of “non-optimality” in vertex attributes if you use client arrays instead of VBOs.

The problem with the semantics of VBOs is that the driver can’t “optimize” the formats in your VBO behind the scenes, because you may update them in the future presuming certain offsets and sizes are valid. Thus the desire for “geometry display lists” or similar in GL3.

Question: what hardware/drivers are we talking about here? On NVidia 8800GTX with any driver in the last 6 months (e.g. 169.09), geometry-only display lists (e.g. containing batches but no state switches) are considerably faster than any VBO implementation I’ve cooked up yet.

I think maybe the NV drivers runs some optimization on the geometry in display lists? Because they often seem to get faster after a few seconds (and VF culling seems to take place too). However, with vertex cache optimizations before submitting VBOs they achieve pretty much same the same as DL. I took note of this on 7800GT and 8800GTS.

Odd. The batches I’m kicking into display lists are definitely vertex cache optimized, and I get a nice boost. I see similar behavior on a 6800 Ultra and a 8800GTX. However, it’s possible there’s some “VBO tickling” that you’ve done that I have not.