Baked Vs unbaked animation

rumblesushi

I heard someone refer to MD2 files as having "baked" animation.

Now I have no knowledge of rigged animation, but I can only assume that baked animation means that there are complete lists of vertex positions per frame, basically rendering the bones redundant, so you'd only have to import the vertex positions, and not the bone data. Is that about correct?

And presumably, un baked animation would export the bones, along with the bone positions per frame, and each bone would control vertices within a certain proximity of it?

I'm just guessing, but logically, that's what I assume.

If that's the case, can I also assume that baked animation would be more appropriate for very low poly stuff (ie DS level polycounts) ?

If my assumptions are correct, baked animation would require less processing, but more ram, compared to unbaked bone animation.

But with high poly stuff, models containing say 25,000 vertices or more, having a complete list of vertex locations per frame would be a LOT of data, and pretty RAM heavy. So I'm imagining that the extra load on the processor for processing bone animation would be the preferred option.

For my needs, baked animation seems like the more attractive option, but are there are disadvantages I should know about apart from RAM usage?

Cheers,
RumbleSushi

locus

You are pretty correct with most of what you said. RAM is a big issue with baked, but it's also not very friendly with modern hardware because it makes it tough for the programmers to perform GPU animations unless they basically upload the entire mesh (and all frames) into video memory. That's not an option if you are aiming for DS. I'd think about rigid weighting with a simple rig or even hierarchical / articulated meshes with key framed transforms. That allows static meshes to sit on the GPU and animations to work with simple matrix transforms. It makes organic stuff all but impossible, though GTA on the PS2 did it like this and no one complained.

renderhjs

rumblesushi wrote: »

For my needs, baked animation seems like the more attractive option, but are there are disadvantages I should know about apart from RAM usage?

1. filesize (one vertex snapshot per keyframe)
2. needs a look up table to calculate the interpolation or tween between the keyframes
3. On big meshes in can be very CPU intense
4. No unique animations, at some point you might see a pattern to the animations.

advantages I found:

1. lets you cache centroids, normals and other stuff as well for every keyframe. No need to calculate it on the fly because you can predict it.
2. You can animate with any stuff in your 3d package, ie. bones, physics system, simple animation,... In the end it gives you more freedom on the creation side

I used a vertex animation on my Curing Colors project and it was fairly ok back then.
http://renderhjs.net/_tmp/soap/vertexAnimations/

On the max side I wrote a simple interface to define the key frames and then export the file into a custom binary file to compress the animation. With the Quake2 format you have define the key frames yourself in a lookup table which I don't like as it creates additional work.

Muzzoid

we use simple rigs with ds stuff, and keep the bone count down by using stretch bones. (things are so small on screen you can get away with making a whole leg have 1 bone and squash instead of bend.)

Also you can only skin a vertex to one bone. No blending at all.

rumblesushi

Locus and Muzz - I probably should have clarified, I'm not actually developing for the DS, it's for a proprietary Flash 3D engine, I used the DS as an example because the capabilities are almost identical - so very similar polycounts.

Of course there are two major differences - everything is done software, and I have much more than 4 megs of RAM to play with.

I could explore both options, as I'll be using constraints for my own car physics etc.

But I quite like the idea of baked animation to be honest. And with models that are between 50 and 150 vertices (approx 100 to 300 triangles) RAM won't be an issue, and file size won't be much of an issue either, unless there's stacks of animation.

The reason I like the idea of it is first it should be less processor intensive, if programmed right, and two - as render pointed out, freedom. You could use as many bones as you want, and it all gets baked, where as with constraints, you'd want to keep the count down, to run as fast as possible.

And render - why is it CPU intensive with big meshes? Because of the extra look up every keyframe? If you did the look ups as part of the same loop, I wouldn't have thought it would make much difference, and still be faster than using constraints to manipulate the verts before projecting them.