Animation resource usage

Started by mystara, August 05, 2009, 10:28:26 AM

Previous topic - Next topic

mystara

Hello!

I was wondering if anyone could give some guidance as to the resource usage of animated models. I'm considering buying some "game ready" animated 3D characters, but I'm not certain whether their use is appropriate for JPCT.

The animation I'm interested in uses 1700 triangles (which seems good). However, it also uses a total of 539 frames.

I'm aware of the excellent thread regarding both the export of max animations to .3ds files and also the stripping of animations. Particularly removing sequences that are of no use.

However, I'm curious as to whether JPCT would be up to importing the entire animation and displaying it 3 or 4 times in a scene. Since each frame would have to be exported as a separate mesh, can I expect an enormous file size and crippled heap?

Is there some way of storing in the animation in a smaller space?
Is it perhaps even possible for a proprietary JPCT format which only stores the changes involved in each vertex to reach the next keyframe? Thus allowing a reduction of heap/disk space.

Sorry for all the questions, I just want to check that it's going to do what I want before I start spending money :)

EgonOlsen

You could do a simple test by loading a mesh with approx. that size and create an animation from it by cloning the mesh and assign it to the animation...do that 528times and you have something in the same range. It doesn't matter if you are using the animation multiple times in a scene as you can assign one animation to multiple objects.

I don't think that a kind of delta only format will save any memory. In the end, the delta is just another 3d vector just like the vertex itself.

mystara

<smacks head>
I was imagining that an increased number of frames would increase the complexity of the processing required to animate an object.
i.e. having 1000 frames would take longer to compute each frame for 500 frames.

But that seems unlikely, since you're always carrying out one mesh change per tick. The only one resource increase should be memory (and disk).