Jump to content
  • Advertisement
Sign in to follow this  
silvia_steven_2000

do we need vertex buffers ? + md2 animation

This topic is 4849 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

why do we need to define vertex buffers ourselves in direct x while we have the ability to use drawIndexedPrimitiveListUp directly from memory. as long as Direct x copies the data from memory to the hardware buffer, why do we need to create it. by the way, I am trying to animate an MD2 model by interpolating frames as usual. I treat each interpolated frame as an indexed hardware vertex buffer that only needs its vertices to change by interpolation. indexes and texture coordinates are the same. the fps crawls when I update the current drawn frame each 1ms. if I update every 100 ms, the fps improves but u get jerky animation. each time I update the vertex buffer I copy the memory vertex array to the hardware vertex buffer using memcpy. where is the bottle neck knowing that animating an md2 model is done like this , u just update the vertices of the interpolation buffer.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Vertex and index buffers can be placed in video memory. Rendering data from the video memory is done much faster than redering data from the system memory.
Also, Draw...UP interfaces support a single stream of vertex data only.

Share this post


Link to post
Share on other sites
As long as you're using Memcpy intelligently then there is no reason whatsoever that transfering vertex information into a buffer is going to be your bottleneck. (If it IS, you've really f@^#%$ up somewhere!)

As for where the exact bottleneck is, we'd have to know more about your program. I'm willing to bet that it may not be a traditional "bottleneck", though, and instead more of a timing issue. You mentioned that you update the frame every millisecond? The way you phrased it, it sounds as if you are taking the number of milliseconds that passed since the last frame and running through your Update Animation routine that many times. Is this true? I certainly hope not, because that would be a horrible waste of processor time. (Especially if you're updating the buffer every time.

Share this post


Link to post
Share on other sites
I do not think I have problems with memcpy. I used it before and it functions fine. I think it is some how related to what u said (timing) but still I am suspicious that there is something related to the buffers. let me describe in more details the way I animate my md2 model. I thought about it twice and I think I have some know problems:

each frame is a mesh that has its own vertex and index buffers, at load time I load the model from file and fill these frames. I was able to render any frame I choose using these buffers. so in total I have created 198 vertex buffer and 198 index buffer for a model of 198 frames and this is not correct. I do not have to create buffers for the frames however the index and vertex buffer needs to be created once for the current drawn interpolated frame. I think there is another problem which is : every time I update the current frame, I copy the new vertices form memory to buffer , this is correct but I used to copy the indexes also and this is not correct I guess since the indexes do not change across frames. the above two problems are what I can see right now but STILL I think there is a timing issue.

here is what I do (recall that this is not the final thing, it is just for testing)

void AnimatedModelNode::onPostRender(unsigned int time)
{
static Real x = 0; //interpolation percent between i and j
static int i = 0; //frame i
static int j = 1; //frame j

//Update current drawn frame every 1 ms
if ((time)%1 == 0)
{
updateCurrentFrame(i, j, x);
}

x += 0.01;
if (x > 1) { x = 0; i++; j++;}
if(j == 197) { i = 0; j = 1; }
}

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!