Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Mithrandir

Performance of updating the vertex buffer every frame?

This topic is 6102 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''d just like to know if updating the vertex buffer of a program every frame is considered to be a bad thing to do or not. Is it slow?

Share this post


Link to post
Share on other sites
Advertisement
Yes it is a bad thing.
In my experimental d3d engine lock() writing and unlock() costs between 20 and 40 frames per second, depending on the system, and the number of vertices you write into the buffer.

Share this post


Link to post
Share on other sites
Funny I was just posting my question near from yours when I saw your post my title would have been:
"How fast is fast"

In my game everythings move and deform, sea , trail , shadow, texture on sky.

So I have mutliple vertex buffer that I lock each frame and with
about 19''000 poly (576000 second) it still run at about 24 fps when the view is very busy. (p400 tnt2 very midle gamer machine)
When I have no boat on view (mean only sea, trail, sun, sky) my FPS increase to 100+fps and I still have the vertex buffer of the sea (3200+400 poly)that is updated each frame.
The main slowdown come with the boat that don''t have vertex buffer changed. (normal x model)

I update each frame independant array with all my vertex value that are computed in real time and copied at the end.
(WRITEONLY)

  
for(i=0;I<NbrVertex;I++)
{
sourcearray.p.x=122.0f;
sourcearray.p.y=12.0f;
sourcearray.p.tu=1.0f;
//etc ...

}
Lock()
memcpy(&vertexbuffer,&sourcearray,Numberofvertice);
unlock()


So while I see so much msg about avoiding locking vertex buffer
I wonder how we are supposed to make real time model such as trail, smoke , sea ect ect...

At least it seam to work for me.

Share this post


Link to post
Share on other sites
Why are you updating the vertices? That''s what the transformation matrices are for.

I almost never lock the vertex buffers (except to fill them initially). In most cases, there is a better way...

Share this post


Link to post
Share on other sites
Sea is impossible to modelise with a tranformation matrice keeping all the control that I have now on it and I also need the value of each poly to clamp the boat onto.
Same for the sail trail that must clamp onto the sea.
And I wonder how doing a missille trail without updating the vertex If you have a solution I will be very glad to ear it.
Sure that for texture moving I must look into projection matrice
(is this the right ways to just scroll a texture?) but this will save only few vertex buffer updating.

Howewer it seem to run fine for now on a medium computer.

Dan

Share this post


Link to post
Share on other sites
I''m updating the vertex''s every frame because that is how my system works.

I am doing my own transformations (special purposes, cant be done with matricies, etc) of objects from object->world->camera space, then sending everything to DX to draw it.

In essence, I want to use DirectX as a rasterizing engine, but not a transformation engine.

Share this post


Link to post
Share on other sites
Mith - just curious, what types of transformations are you doing? One possible answer is to go with shaders, but you can do quite a bit with matrices.

Dan - I''m not sure exactly what you want out of a missle trail, but you would probably be able to do *something* with the matrices.

Also, to change the texture coordinates, use a texture matrix, not the projection matrix.

If both of you are getting acceptable framerates, that''s good. The point is that it may be easy to make changes that free up more horsepower for new features. (maybe??)

Share this post


Link to post
Share on other sites
Writing vertices on real-time every frame is OK (when needed)
The SDK documentation has a couple of pages about Dynamic vertex buffers and their usage (presenting 3 different methods to lock/fill/unlock, one of them requiring at least thousands of vertices per frame)

The CD3DFont class uses a dynamic vertex buffer filled with vertices on each call.

If your vertices are static, make them static, otherwise don''t

Share this post


Link to post
Share on other sites
quote:
Original post by CrazedGenius
Dan - I'm not sure exactly what you want out of a missle trail, but you would probably be able to do *something* with the matrices.



I will really be glad that can work with matrice but I cannot see any solution for that.

In fact a loooong trail that follow a missile can only be created in real time so I transform the point of the rear bounding box into world point and create my polygon

let me try ascii art



fig 1:
poly
******* missile
* * -------------* * -------------/
*******

fig 2:
when it reach a certain height the poly is broken and another one started so we have smooth curve. (strip)

those two vertex follow the missle until
height is reached
|
poly |
************** missile
* * * -------------* * * -------------/
**************


While an image worth thousand word here was my first test:



and the result:


As you see matrix cannot help here or I missed something :-)

Dan

Edited by - dansteph on October 31, 2001 5:07:22 PM

Share this post


Link to post
Share on other sites
That looks pretty darn good!

I also have a situation that might require updating the vertex buffer per frame. I have a particle system with a vertex buffer of a set size that holds all the vertices for the particles. Now the particles have to move in all sorts of different directions, so I manipulate the attributes of the individual particles, then refill the vertex buffer, then render them all in a big bunch. They say that you should batch polys as much as possible, so whats slower, refilling the vertex buffer or rendering 2000 triangles 2 at a time (1000 calls to DrawPrimitive!)?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!