PDA

View Full Version : Real-time mesh editors with VBOs



charlie mac
03-07-2008, 12:04 AM
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.

Zengar
03-07-2008, 01:51 AM
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

zeoverlord
03-07-2008, 05:46 AM
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.

charlie mac
03-07-2008, 03:13 PM
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?

Zengar
03-07-2008, 03:19 PM
In comparison to VBOs that are not updated very often ))

charlie mac
03-07-2008, 03:34 PM
Touché

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?

Zengar
03-07-2008, 04:23 PM
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.

zeoverlord
03-08-2008, 09:39 AM
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

CatDog
03-08-2008, 10:41 AM
Here (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=165665#Post165665) is what Michael Gold answered to a similar question. (Afaik he is or was ARB member before the silence started.)

CatDog

Dark Photon
03-10-2008, 06:26 AM
... and there is no way VBOs could be slower then usual client-side arrays --- if it happens, driver developers must have screwed really bad.
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.

Dark Photon
03-10-2008, 06:33 AM
And while display lists may be slightly faster they are significantly slower than VBO and less dynamic than immediate mode
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.

Nicolai de Haan Brøgger
03-10-2008, 11:27 AM
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.

Dark Photon
03-10-2008, 11:47 AM
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.