Jump to content
  • Advertisement
Sign in to follow this  
Riggzy

Efficient 3d character animation

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

Hi,

I'm currently studying games tech at uni and doing my fist unit in games design. My team and I have developed a way to import models and their texture details from 3dsMax (reading .obj files) and recently i have extended this to import "animations" as well.

At the moment i have made a small program which reads in a .obj file for each frame of the character animation. I then store the frame number, face number, vertex number (0-2 because each face is a triangle), and x y or z value in a 4d dynamic array. I use this array to calculate the vertex differences between each frame and store the differences in a 4d array.

For animation in my test program i use this differences array to modify the vertex values of the 3d model and the animation works fine. However the current model I'm animating has about 600 faces, which means 600 iterations (with 9 operations) per frame for one character...

Is this an inefficient way of animating? If so, what other techniques could i use to improve efficiency?

Any help would be greatly appreciated.

Share this post


Link to post
Share on other sites
Advertisement
I suggest you to seek "bone animation". If I recall correctly .obj do not stores bones, thus is not a good format to use for animations and the the technique i just told you to use.

It will reduce interpolations on animation to only those needed for bones, and later on you will only need to skin the vertex of your model to the bones matrix you calculated.

Share this post


Link to post
Share on other sites
To augment what kilah mentioned, rather than "tweening," which is essentially what you're doing with deltas between vertex positions, it is more common and probably much more efficient (given a compatible file format) to assign one or more "bones" as influencing each vertex. Those bones are actually matrices. Those matrices are then modified each frame, written into an array of matrices in a shader. When the model is rendered, each vertex (unmodified), which includes indices to the bones which influence that vertex, is sent to the shader, the shader performs a matrix multiplication (based on the indices of the "influence" bones) and sends the animated position on through the pipeline.

Share this post


Link to post
Share on other sites
alternatively, do a sun dance and the gods will inscribe a fully debugged, c++ code into the nearest cliff of your location :D

But jesus Riggzy, i'm still in the middle of putting that banner in shays code! I better get a move on.

Share this post


Link to post
Share on other sites
Vertex interpolation is going to be faster than using bones. If you want it faster you can always offload the interpolation to a vertex shader (ie pass the frame position and next frame position as vertex attributes).
The only problem might be memory consumption as it adds up fairly quickly as your models get more complex, you add more animations or you add more frames to your animations. You can always keep them compressed in memory and decompress in a vertex shader, but at that point it's probably better to switch to bones.

Share this post


Link to post
Share on other sites
Quote:
Original post by BertS
Vertex interpolation is going to be faster than using bones.


That depends on how many vertices you have to tween. Depending on how much vertex data you have to tween, it would be fairly easy to exceed your CPU cache, which can cause fairly serious performance drops. Skinning is only more 'efficient' in those cases due to less memory being used. This difference is hidden in GPU's to some extent (due to lots of fast ram), but it's still an issue to be aware of.

Quote:
The only problem might be memory consumption


Which is a *HUGE* problem! Memory reads are the slowest operations you can perform on a modern CPU. Given the size of the OP's meshes though, this really won't be a huge problem.

Quote:
You can always keep them compressed in memory and decompress in a vertex shader, but at that point it's probably better to switch to bones.

Compressing data is almost always a performance win.

Share this post


Link to post
Share on other sites
Riggzy is asking for an efficient technique, not fastest.

Morph targets might be faster on most cases (since you directly pass a new transform for each vertex precalculated within the modeling tool you use), and is much more interesting for animators than bone animation as they have a way easier and more acurrated control than bone animation.

Yet for full body animations no one uses it(morph target is useful for face animation), and there are several reason for that, memory consumption is one of the main ones, but there are more.

I'll keep my suggestion, stick with bone animation for efficiency, specially if you have or want more animations within your game, the memory cost of morph targets can be just prohibitively even for PCs.

Share this post


Link to post
Share on other sites
Quote:
Original post by kilah
Yet for full body animations no one uses it(morph target is useful for face animation), and there are several reason for that, memory consumption is one of the main ones, but there are more.


Morph Targets and tweening are not the same thing. Tweening uses straightforward linear interpolation. Morph targets uses a weighted sum of the target offsets. If you have 1 base mesh, and exactly 1 target, then it's identical to tweening. In all other cases the computation is very different indeed.

Quote:
Yet for full body animations no one uses it(morph target is useful for face animation), and there are several reason for that, memory consumption is one of the main ones, but there are more.


Morph targets are frequently used all over the body. i.e. Muscle deformations, breathing, skinning fixes around shoulders/elbows/knees etc. The niceness about Morph targets is that it can be assumed that the deformation of each target is localalised. That data can therefore be pre-processed to remove offsets of zero magnitude. In general, the memory usage for all of the morph targets on a mesh rarely exceeds the memory usage of the original mesh data. (If it does, you're doing it wrong). With tweening you will be duplicating the mesh for every single frame. So yes, morph targets are efficient, but that doesn't mean tweening is.

Quote:
the memory cost of morph targets can be just prohibitively even for PCs


Now you are talking about tweening. The memory cost of morph targets is not prohibitive by any stretch of the imagination.

Share this post


Link to post
Share on other sites
Thank you everyone for your input. This is the first thread i have put on the forum and I'm rather impressed by the quality and quantity of the responses.

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!