Jump to content

  • Log In with Google      Sign In   
  • Create Account

Matrix Multiplication vs Compression Dilemma


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Kwizatz   GDNet+   -  Reputation: 1199

Like
0Likes
Like

Posted 18 September 2012 - 03:28 PM

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! Posted Image

Edited by Kwizatz, 18 September 2012 - 03:32 PM.


Sponsor:

#2 Álvaro   Crossbones+   -  Reputation: 13308

Like
1Likes
Like

Posted 18 September 2012 - 04:39 PM

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?

#3 Kwizatz   GDNet+   -  Reputation: 1199

Like
0Likes
Like

Posted 18 September 2012 - 05:25 PM

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 Posted Image.

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

Thanks!

Edited by Kwizatz, 18 September 2012 - 05:36 PM.


#4 Álvaro   Crossbones+   -  Reputation: 13308

Like
0Likes
Like

Posted 18 September 2012 - 05:48 PM

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.

Edited by alvaro, 18 September 2012 - 05:49 PM.


#5 Kwizatz   GDNet+   -  Reputation: 1199

Like
0Likes
Like

Posted 18 September 2012 - 07:14 PM

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!

#6 Kwizatz   GDNet+   -  Reputation: 1199

Like
0Likes
Like

Posted 20 September 2012 - 11:43 AM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS