There are static and dynamic. What exactly are the capabilities of a static buffer? I mean, if I load a mesh and store its vertex info in a static VB can I animate that mesh and have the buffer still be static? Or does this require a dynamic vertex buffer? I think that static will work but I can''t be sure from reading the SDK, at least nothing in it says for sure that I''ve found. TIA, Webby

To be safe use dynamic for animated objects - unless your going to write some simple code to do animation with it - (this is just general - im not an expert on vertex buffers so you may want to wait for some more replys before moving on)

So the terrain should go into a static buffer but anything that has an animation should go into dynamic buffer/s.

Works for me.
Thanks all,
Webby

Hmmm. Confusing. How can the vertex values remain the same of the mesh is being animated? This is a bridge I won''t officially be crossing for a while on the animation side so I can go on and do the terrain part with a static buffer and then figure out what I need for the animation stuff. That will probably be dynamic buffers as I am currently planning to use keyframes. I have no current idea on how to do animation with shaders as shaders are something still very foreign to me.

You mention vertices being manipulated by bones but the mesh remains the same. I''m not understanding how this is possible. If a bone moves an arm, don''t the vertices in the arm have to change to reflect the movement? Then doesn''t this justify the use of a dynamic buffer.

I''m thinking I''ll go with dynamic buffers for characters no matter what type of animation. This way I''m not locked in to using keyframes if I want to move into vertex shaders. OTOT, if I used static then as you noted, moving to shader animation would require switching to dynamic buffers.

On a side topic, using dynamic buffers does the process of animating go like this
Load the mesh and animation data.
Put the current animation frame into the buffer and render it.
When I get to the next animation frame I clear the buffer and load the newly moved vertices into the buffer and render that.
Based on this, I will likely be dumping and reloading the buffer
each frame since it isn''t likely that characters will be sitting still. Of course I can check if they do sit still and just not dump/reload the buffer if this is the odd case.

Is this correct?
TIA
Webby

It''s not that confusing... If a hardware shader is affecting vertices, it affects data as it''s flowing through the pipeline... the data in the buffer doesn''t change. Same applies using hardware T&L fixed pipeline.

When using software shaders or software T&L, the data must be modified by the CPU, and sent to the card each time it''s needed.

Whether the GPU is affecting the data doesn''t affect which buffer to use. If the CPU isn''t modifying the data, it can be placed in a static buffer. If the CPU is modifying the data, it needs to be dynamic.

quote:Original post by WebsiteWill
Hmmm. Confusing. How can the vertex values remain the same of the mesh is being animated? This is a bridge I won''t officially be crossing for a while on the animation side so I can go on and do the terrain part with a static buffer and then figure out what I need for the animation stuff. That will probably be dynamic buffers as I am currently planning to use keyframes. I have no current idea on how to do animation with shaders as shaders are something still very foreign to me.

You mention vertices being manipulated by bones but the mesh remains the same. I''m not understanding how this is possible. If a bone moves an arm, don''t the vertices in the arm have to change to reflect the movement? Then doesn''t this justify the use of a dynamic buffer.

No, when using bones you don''t need to use a dynamic buffer. What you would do is load your mesh data into a static buffer, and then draw those verticies from model space into world space using a number of different matricies.

Interesting.
I just read the first two articles on vertex shaders on this site and all I can say is WOW. I had some ideas on how I was going to handle some lighting schemes and such but now that''s completely out of the water. I think that after I get a grip on what kinds of buffers I will use I will then spend a few days getting mroe acquainted with these shaders. I saw a book the other day at B&N on shaders but I passed it over as not being immediately important. Boy was I wrong.

Thanks all for opening new avenues!
Webby