View Full Version : fast dynamic mesh

08-22-2009, 09:40 PM
I'm looking for the fastest way to implement a dynamic mesh and would appreciate any advice.

My mesh contains a large number of triangles(500k) and on each frame the location/color of each vertex can change. I need a stereo image so each frame gets rendered twice with just a change in camera location. There is no dynamic lighting, texture mapping or anything else.

The two main possibilities i've considered are:

A) vertex buffer objects and altering the vertex locations/colours via CPU and then rendering it once for each eye

B) Having a static mesh preloaded and transforming it using a vertex shader on the GPU. Deformations are from a texture which is loaded each frame. Again it's then rendered once for each eye.

With option B, given that the vertices are the same for each eye, would the vertex positions be cached and then re-used for the second eye, or would they be recomputed? I'm guessing if they are recomputed then this may be slower than option A

Any advice?

Ilian Dinev
08-22-2009, 11:27 PM
Elaborate on how/why/how-many of those 500k tris' vertices change each frame. It could turn-out just updating small parts of the mesh could be enough, or doing it all in the gpu is feasible.

Vertex cache is only 24-32 entries, and flushed on each state-change (buffer-bind, shader-bind, etc). Anyway since the transformation matrix for the second eye is completely different, you can't/shouldn't/needn't reuse vtx-shader output across frames.
Just in case, to note that for stereo you don't need dynamic meshes - just sending an appropriate MVP matrix and redrawing the frame is necessary.

08-23-2009, 03:14 AM
Pretty much every vertex location/colour is altered very frame - but doesn't change between creating the images for each eye.

In that case I guess it's probably faster to edit the vertices on the CPU, shuffle them across to a vbo and then render the two frames from that?

Ilian Dinev
08-23-2009, 10:32 AM
Yes, your best bet is to upload to a dynamic VBO. Try to keep as much of the static vtx-attribs/IBO into a static buffer.

Dark Photon
08-23-2009, 12:30 PM
Also don't forget to try pure client arrays (non-VBO vertex arrays). Might possibly be faster depending on your GPU and drivers.

However, the forward-looking thing to say is use VBOs.

08-24-2009, 01:25 AM
Also don't forget to try pure client arrays (non-VBO vertex arrays). Might possibly be faster depending on your GPU and drivers.

Considering, he has to render a frame twice, this is unlikely to be faster than VBO.

I'd go for just updating VBO, bud depending on the way the data changes across frame I would probably consider keeping vertex coordinates in a texture and updating it by rendering diectly to this texture.
The trick is that you sometimes need less data or less precise representation to show differences between frames. So, you could keep vertex information in RGB32F texture, and update it by sending RGB16F texture or even using GL_EXT_texture_shared_exponent.

This would add an extra cost to rendering but would decrease amount of data that needs to be sent to GPU by 2x or even 4x.

Once every n frames a full update would be performed.

The only problem is converting source data into differential-data in RGB16F or shared exponent formats on the CPU. This would be probably only partially accomplished while GPU renders these 500k polys.

08-24-2009, 03:15 AM
1.ur animation is key-frame or skeletal-animation?

u can man all your animation on the v-ram and set pointer in every call of vbo(vertex_address * animation frame). i think this is faster but have problrm with big animations and get very big amount of memory