Performance of updating the vertex buffer every frame?
Thats exactly what I''ve been trying to find out with my posts (moving D3D points quickly)... Its really stumping me how I''m suppose to "animate" objects without locking... The particle system is a great example of a situation I''m thinking of... I hope someone answers soon... CrazedGenius please save us!
I can tell you for a fact that for a particle system of any significant size, you CANNOT use transformation matrices (except in very special situations...), because of a major slowdown. This comes from a test I did a while abck while working on a fire p system. The particles had to scale down as they went up (so the fire tapered). To get an acceptable frame rate, i had to clamp the number of particles in the system to 8. On the other hand, for a snow system, i had 650 particles going at once (my vid card really sucks, to explain the low numbers). Both systems lock on every frame, but the fire system had to set a scaling matrix, and render each particle individually, while the snow just set a simgle scale matrix as per the first particle, and then drew every particle in a single call.
The only real situation that i can think of at the moment is for a particle system in the basic shape of a sphere that is scaled up or down.
Z.
The only real situation that i can think of at the moment is for a particle system in the basic shape of a sphere that is scaled up or down.
Z.
Whenever you need to modify the vertices in an object individually instead of the object as an aggregate, you cannot just use a transformation matrix (because all vertices are affected uniformly). You do have a few options:
1) Lock the vertex buffer and update it. If you do this, you obviously need to minimize lock calls, and work on local copies -- never READ the buffer.
2) Store different meshes for different frames of the animation, and just display the appropriate mesh. This is the fastest (and usually takes the most memory) way, but obviously only works if animation is predicatable and small enough to store.
3)Try to fake if with textures.
4) Divide the mesh into subcomponents and use one of the above on each portion.
Which method you choose depends on what you are trying to do and what you are willing to pay in terms of flexibilty vs performance. Its not necessarily "bad" to lock the buffer; it is bad to not use locks as minimally or efficiently as possible (ie. don''t lock and copy on every frame -- only on those frames where something visible has changed).
1) Lock the vertex buffer and update it. If you do this, you obviously need to minimize lock calls, and work on local copies -- never READ the buffer.
2) Store different meshes for different frames of the animation, and just display the appropriate mesh. This is the fastest (and usually takes the most memory) way, but obviously only works if animation is predicatable and small enough to store.
3)Try to fake if with textures.
4) Divide the mesh into subcomponents and use one of the above on each portion.
Which method you choose depends on what you are trying to do and what you are willing to pay in terms of flexibilty vs performance. Its not necessarily "bad" to lock the buffer; it is bad to not use locks as minimally or efficiently as possible (ie. don''t lock and copy on every frame -- only on those frames where something visible has changed).
quote:Original post by Moe
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!)?
G''day!
In a situation like this, locking and updating your VB is going to be much faster than drawing them individually. When doing this, make your VB''s write-only and lock using DISCARD. If you need read-write, then have an array of vertices that you update, then lock the VB (again using discard) and copy your array in.
Stay Casual,
Ken
Drunken Hyena
As ususal, this post is about a month too late for me. I had a problem stretching a VB (couldn''t use Matrix transforms because only the y cood changed and it is relative to the x coord). DISCARD (it took me 2 weeks to change that) made a big difference, as well as only changing the .z coords that needed changing and leaving all the rest. I ended up only having 20 lines (in a 200 vert mesh) of code between ->lock() and ->unlock(), but i still had to pay about 18-20 fps for it. I guess it comes down to can you afford the fps for the effect (and if YOU can''t, you can always set the system requirements to something bigger than YOU own hehehe). btw that is some very nice rendering with the ship and missile there (i like the waves too)
Brett Lynnes
cheez_keeper@hotmail.com
Brett Lynnes
cheez_keeper@hotmail.com
Author
Now, maybe i''m just not understanding what use Vertex buffers are for.
I mean, are you supposed to have 50 million VB''s, one for each object, or what?
Or are you supposed to have one big VB, representing every object in the system? How then, does one remove objects from the system without totally mucking up the VB?
I''m just very confused, VB''s seem like a bloated piece of crap that has absolutely no real-world use.
I mean, are you supposed to have 50 million VB''s, one for each object, or what?
Or are you supposed to have one big VB, representing every object in the system? How then, does one remove objects from the system without totally mucking up the VB?
I''m just very confused, VB''s seem like a bloated piece of crap that has absolutely no real-world use.
It really depends on the project. I have 2 examples of the extremes.
Example 1:
I had a 3D Scene that had one part of it moving but the rest was fairly static. I created one HUGE vb with everything in it. Drew the first several hundered triangles using strips and fans, then drew the remaining moving buffer using triangle lists. all a VB holds is the points, so you can choose where to start and stop rendering those points (ie. do the world matrix move and THEN render a triangle list from vertex 2801 for 12 triangles)
I also have a 2D one where I maintain about 70 different arrays of VBs... I like this better for 2D because it gives me more control (i have to ->Lock and ->Unlock) but it does make for some nasty init/drawing/update routines... infact I had to spilt up the file 4 times JUST to keep track of the VBs without having 100K lines of code in a file....
both ways run at very resonable speeds. I have heard that having EVERTHING in one VB can go quicker on the newer cards, but seriously you should look at practicality of programming rather than speed in this.
Brett Lynnes
cheez_keeper@hotmail.com
Example 1:
I had a 3D Scene that had one part of it moving but the rest was fairly static. I created one HUGE vb with everything in it. Drew the first several hundered triangles using strips and fans, then drew the remaining moving buffer using triangle lists. all a VB holds is the points, so you can choose where to start and stop rendering those points (ie. do the world matrix move and THEN render a triangle list from vertex 2801 for 12 triangles)
I also have a 2D one where I maintain about 70 different arrays of VBs... I like this better for 2D because it gives me more control (i have to ->Lock and ->Unlock) but it does make for some nasty init/drawing/update routines... infact I had to spilt up the file 4 times JUST to keep track of the VBs without having 100K lines of code in a file....
both ways run at very resonable speeds. I have heard that having EVERTHING in one VB can go quicker on the newer cards, but seriously you should look at practicality of programming rather than speed in this.
Brett Lynnes
cheez_keeper@hotmail.com
Want to know something scary? In the DirectX SDK for the one using point sprites, they draw each particle seperately so they can make them look like they streak.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
