Performance of updating the vertex buffer every frame?
Author
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?
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.
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.
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)
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.
"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.
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...
I almost never lock the vertex buffers (except to fill them initially). In most cases, there is a better way...
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
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
Author
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.
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.
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??)
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??)
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
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
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
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!)?
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!)?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
