Sign in to follow this  
Raeldor

Vertex buffers... dynamic?

Recommended Posts

Is it possible to build some kind of dynamic vertex buffer. For example I don't know how many vertices I will have until I walk though and process my quadtree, and I don't really want to walk through it twice (once to count vertices and second to build the primitive). How can I build a vertex array that grows, or is there another technique that is better and/or more efficient. Thanks.

Share this post


Link to post
Share on other sites
struct vertex3f
{
float x,y,z;
vertex3f( float x , float y , float z )
: x( x )
, y( y )
, z( z )
{
}
//...
};

std::vector< vertex3f > verticies;

void walk_through_and_process_my_quadtree( void )
{
//...
verticies.push_back( vertex3f( 0.0 , 2.3 , -12.0 ) );
vertex3f foo( ... );
verticies.push_back( foo );
//...
}

void call_glVertex3f_on_each_vertex( void )
{
for ( int i = 0 ; i < verticies.size() ; ++i )
{
vertex3f & v = verticies[i];
glVertex3f( v.x , v.y , v.z );
}
}


Share this post


Link to post
Share on other sites
Vertex buffers don't need to be filled completely, nor do you need to collect everything before rendering. Just make it a good size, and as it becomes too full, unlock, render, lock with discard, and start filling more. More often than not though, you don't need to dynamically build a list of vertices.

You should only be using dynamic buffers and building vertex lists dynamically for things where the geometry changes constantly, AND where these changes are not done via a shader. Swaying trees, skinned characters, etc, can all be done in a shader. vs_1_1 shaders are a pretty common minimum requirement these days, and by the time you're done working on whatever you're doing, you can pretty much rely on shader capable cards being in all machines.

Each chunk of your static world data should already be sitting on the GPU in video memory in a static buffer. Each dynamically movable object should also be sitting in static GPU memory. Your quadtree should simply determine if the objects are visible, and add those objects to a list to be rendered. You should not, generally, build vertex lists. It's faster for the GPU to cull out the half of a building that's off screen than it is for you to try and cull at that level.

Share this post


Link to post
Share on other sites
Quote:
Original post by Namethatnobodyelsetook
Vertex buffers don't need to be filled completely, nor do you need to collect everything before rendering. Just make it a good size, and as it becomes too full, unlock, render, lock with discard, and start filling more. More often than not though, you don't need to dynamically build a list of vertices.

You should only be using dynamic buffers and building vertex lists dynamically for things where the geometry changes constantly, AND where these changes are not done via a shader. Swaying trees, skinned characters, etc, can all be done in a shader. vs_1_1 shaders are a pretty common minimum requirement these days, and by the time you're done working on whatever you're doing, you can pretty much rely on shader capable cards being in all machines.

Each chunk of your static world data should already be sitting on the GPU in video memory in a static buffer. Each dynamically movable object should also be sitting in static GPU memory. Your quadtree should simply determine if the objects are visible, and add those objects to a list to be rendered. You should not, generally, build vertex lists. It's faster for the GPU to cull out the half of a building that's off screen than it is for you to try and cull at that level.


Hmm, what about for a dynamic terrain LOD algorithm using a binary triangle tree? Depending on the camera position the terrain tessellation will change the number of primitives.

Regards

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this