I am almost done with my skeletal animation file format specification, but I have come across a dilemma.

I am using animation channels which are arrays containing one value per frame, I came up with the idea of not storing the array if all the values are the same, so the value is stored only once, I call this, obviously, a constant channel.

From there I thought I could do something about other channels that change too little, for example for some sort of trigger channel, where values are mostly zeros with ones here and there to signal a sound or that a footprints, so I added Run Length Encoding channels.

So far so good but! once I came to store joint transformations I noticed that when I store full model space transforms, the children joints change as the parent changes because the transform 'includes' the parent's transform, so transformation vectors do not compress well this way.

However, if I store the joint transforms in 'parent space', if a joint never moves or rotates or scales, its values never change and thus, very good compression ratios can be achieved.

Now, the problem is that if I store the transforms in parent space, I still need to calculate the transforms in model space at run time, and that may involve several matrix multiplications that are avoided if the transforms are precomputed as is in the first case.

So my question is... what should I do? should I go for (perceived) speed or size? is this even a valid concern? perhaps the overhead is negligible, or maybe a smaller memory footprint compensates for the computation cost, I don't know.

Ideas? Discuss!

So my question is... what should I do? should I go for (perceived) speed or size? is this even a valid concern? perhaps the overhead is negligible, or maybe a smaller memory footprint compensates for the computation cost, I don't know.

Don't go for perceived anything. Measure instead. Chances are the extra matrix multiplications aren't that expensive, since hardware has been optimized for that type of operation since computers were invented. Also, do you really need to compress all that much? How much animation data do you have and what platform is this for?

Hi alvaro,

Well, the idea is for a general engine, but to be more specific I am targeting PC's (Windows, Linux) and Android, so going by the lowest denominator, lets say its for handheld devices, ARM processors.

Right now I don't have that much animation data, an uncompressed idle character loop is about 500k with just joint information, no morphs, quite insignificant, I know, but I like the idea of shaving as much as possible so it does not add up to a lot later on when I have more characters, vehicles, etc.

I could add a flag and allow the format to be flexible and let the asset pipeline decide based on where the files would be used, but if there really is no gain, I don't see why add the complexity.

You're right, I should measure... kind of what I was trying to avoid .

I do realize this is probably early optimization, but I kind of want to nail down the format once and for all.

Thanks!

I agree that it is early optimization. At this stage I would just spend some effort in making the animation representation modular, so you can implement other methods later on without having to change interfaces. You can then optimize when you have actual test cases.

On a related note, I think it only makes sense to write an engine by writing several games and then extracting the parts that have proven to be useful across projects (perhaps with a bit of reshaping to make them more engine worthy). More generally, that's a good approach for writing libraries of pretty much any type.

I'll just add a flags variable to the file header and add one for this, the flags may be useful for something else later on.

Thanks!

So, I know this is a very particular issue and maybe in the end a matter of taste, but just in case someone runs into a similar issue...
I found that storing parent space transforms may be the best approach after all since I am seeing some artifacts for interpolated frames that might be due to interpolating between model space transforms, so calculating each joint model space matrix at run time might be the best approach unless you don't mind jiggly animations (the closer you are to the model the more noticeable the artifacts are).

If you don't interpolate frames, then you're ok.