Jump to content
  • Advertisement
Sign in to follow this  
owl

Tips to cache skeletal animation frames

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

Imagine you got your model attached to a skeleton and an animation running and getting updated every frame or so. Is there an already discovered way to avoid having to calculate the vertices transformation each frame? What would be a good way of catching them? Storing several arrays per model at a given time of the animation and storing the proper transformation there?

I'm kind of lost here. Any tip would be appreciated.

Share this post


Link to post
Share on other sites
Advertisement
If you update your skeletal animation every frame, you also have to deform your vertices every frame, assuming that the animation is changing.
However, if for some reason you want to cache this, maybe for LOD reasons, you could use the stream out functionality of Direct X for example. This lets you output the skinned vertex data into a vertex buffer, so that you can reuse this without having to re-skin it again.

In case you mean skeletal animation caching for non-fixed sampled animations, you can store an array of indices to the first of the pair of keys that you use to do interpolation between. That can speed up the costly process of finding the right keys to use for interpolation.

You can also decrease the update rate. Updating it only at a given frequency, say 15 fps for models in the distance.

I'm not sure if that answers your question though. If not, can you explain a bit more what you are trying to achieve?

Share this post


Link to post
Share on other sites
Hi thanks.

I'm animating skeleton based models with a library called Cal3D. This library has the original model and, each frame it is asked to, given the amount of seconds elapsed it calculates the new pose of the skeleton and writes the modified model vertices over a given buffer.

I'm currently capping the number of frames per sencond, but still, if the number of simultaneous animations are more than 15-20 (with models around 2500 vertices, 120k buffer) the framerate goes down badly. I was hoping there was some sort of magical hack to improve this. I certainly can't come up with any myself beyond pre-calculating all the animation frames once and rendering them directly.

Share this post


Link to post
Share on other sites
You should have a look into skinning inside a vertex shader.
That way you can push a lot more character and you do not need Cal3D to process the vertex data each update, but only let it update the bone transformation matrices.

I don't know Cal3D, but I assume it is possible with that library.

Or are there any specific reasons why you want to do this on the CPU instead of on the GPU?

Share this post


Link to post
Share on other sites
heh, I'm not working with very modern hardware right now. That's mostly the reason. Also I'd like to keep support for legacy video cards as far back as I can.

Share this post


Link to post
Share on other sites
You realize that 10 year old video cards can already handle skinning on the GPU right? :) I understand if you work on phone hardware it is an issue. Although even newer phones should support it. One idea might be that you use GPU skinning on the "modern" GPUs, covering GPUs up to 10 years old, and keep the software skinning for the other older hardware.

You can use LOD techniques to speed up things up on the CPU skinning side. Other optimizations you might want to consider are accelerating it by SIMD or even multi-threading. You can also update at lower frequencies.

Share this post


Link to post
Share on other sites
We are talking about GForce 440 MX here :) It doesn't even has vertex shader 1.0, at least not the one I'm using right now. I do want to support modern features for new hardware, so yes, I plan to switch available extensions and the like whenever they are available.

LOD is certainly one thing to keep in mind, thank you for that tip. I think Cal3D has some capability for it. The project I'm currently working on though can't take advantage of it as the models remain always at the same distance from the camera. I already capped the update ratio of the animations. I plan to make that value configurable at some point so those who have the right computer can run them the smoothest as possible.

I was thinking more about some technique that wouldn't be dependent on hardware features. But I really don't think there is much more beyond what you suggested. Thanks.

Share this post


Link to post
Share on other sites
create 2 groups of characters. update one set of skins one frame, the rest on the next frame. The update frequency of each model will remain exactly the same, however your frame rate will have doubled. Generally it's still a good idea to update the animation hierarchy each frame though.

Share this post


Link to post
Share on other sites

You realize that 10 year old video cards can already handle skinning on the GPU right? :)

He might not realise that, mainly because it's not true.
The only card that's 10 years old that handles skinning is the geforce 3.


Share this post


Link to post
Share on other sites

He might not realise that, mainly because it's not true.
The only card that's 10 years old that handles skinning is the geforce 3.


I'm trying to show that since Geforce 3 most hardware supports shaders. And that this card was already there 10 years ago.
Since he is talking about modern hardware only being able to do skinning on the GPU, while a 10 year old card can already do this. If his problem is performance he might rethink his strategy regarding hardware requirements, and try to make his game look best on most hardware. And a bit less detailed on the real old hardware that has no shader support.

If I remember correctly you can even do some basic hardware skinning on hardware that doesn't even support shaders.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!