Sign in to follow this  

Rendering Large Numbers Of Animated Meshes

This topic is 4342 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 have written something approaching an RTS in 3D. However, the primary stumbling block of my code is that when I render more than 4 animated MD2 models on screen, the framerate slips below 10 fps. I've discovered that it is my animation code which is slowing this down, the actual rendering of the models is very fast indeed. The model animation code is not particularly efficient and it's done on the CPU. (I've not had time to offload that to the GPU) I'm wondering what I could possibly do to speed up my model animation (basically I'm LERPing between lots of stored vertex key frames in memory). Also, I've got a problem with clicking terrain. I can do the math for casting a ray to terrain (triangle-ray intersection) and have implemented it in code, however, I have to loop through 128*128 terrain tiles on each click and check each one for collision. This can take almost a second, which is unacceptable when combined with the slow framerates I already have. What can I do to speed up this search?

Share this post


Link to post
Share on other sites
Quote:
Original post by RobTheBloke
you should be able to do a 100 to 200 models on the CPU running at about 60fps. link to my MD2 viewer..... you might get a few idea's from looking at the source.


Yes, that's basically what I'm doing too, except I'm calculating averaged normals for each model each frame, which may be the bottleneck. I'm thinking I should offload that processing to the GPU.

Edit: Hmm, it seems that it may be the animation after all, removing the normal calculations doesn't seem to make much difference.

Edit: I'm using DirectX Meshes, and when I remove the render call (m_pMesh->DrawSubset( 0 );) the code processes very fast. This means that the animation is not infact the bottleneck but in fact, the mesh itself must be very inefficiently stored. How can I go about solving this problem? Should I switch from using meshes to vertex and index buffers instead. This is perplexing. :(

[Edited by - Leo_E_49 on January 26, 2006 2:45:06 PM]

Share this post


Link to post
Share on other sites
Offload animation to GPU, lerp two positions and normals in the vertex shader. Just store both pos,norm in single vertex.

Subdivide the terrain into pieces, and test only needed pieces.
One thing you need for sure, is height in a given spot of the plane (for unit<->terrain collision) and you need to implement it so it will be very fast.
If you have that done - just start from the camera, increment (x,y) by the viewing vector, and test the height - if it goes below the terrain - this is the intersection.
Of course, you can refine the point by binary search, etc...

Share this post


Link to post
Share on other sites
if you are working with rotation interpolation i would rather suggest the use of slerp instead of lerp

why?

slerp interpolates the rotations at the surface of the sphere whereas lerp just interpolates the direct connection

imagine 2 points rotated around the rotation origin

if use lerp with some factor t it will adjust the vertex position on the connecting line (a,b)

so the further you get into the middle of the connection the faster the rotation angle will change which results strange deformations sometimes(not always) this also depends on the number of animation frames , the more frames the less difference between vertex positions => less deformations


now spherical interpolation changes the angle progressively with constant difference between current and last frame

Share this post


Link to post
Share on other sites
Here is the conclusion I did ended with when I toggled a similar problem a few months ago ;

- LERP is ok for an RTS with MD2 models (cheaper and precise enough as long as you're not looking to close to the units and even it would not matter since you are using MD2 which is a low precision format and you would get artifacts anyway),

- You really should give the interpolation work to the GPU. I use OpenGL and make it this way ; one vertex buffer object per animation which holds all informations (coordinates, normals, texture coordinates), one vertex program which performs the interpolation. Even if the hardware does not support vertex program, most drivers support it in software and will do a good job.

- When interpolating, it is not really usefull to normalize the normal (normals are not precise in MD2 format anyway). It depends on your model but for mine it appeared that normalizing required quite a lot of power for nearly no visual gain.

- I don't know if you are already doing it but you really should group the rendering per model type in order to avoid switching the textures and VBO (i.e. you first render you terrain, then send all the units using the model XXX1.MD2, then all the units using XXX2.MD2 and so on).

- You should use compressed texture ; this is very easy (at least under OpenGL) and gives a small performance boost (around 10% for me).

- Intersections against the terrain are a bit difficult to perform preciselyat a low cost. A hack to perform this easily is to first compute the intersection of the viewing ray with a flat plane to get a rough intersection point. Then check against the terrain patch corresponding to this rough intersection point and extend to the neighbour patches until you find your final intersection. This will only perfoms ok for nearly flat terrain / terrain which are looked from above, and relatively big patches. It is the case in my project and I nearly never have to check the neighbour patches.

Share this post


Link to post
Share on other sites

This topic is 4342 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this