New Animation System for Irrlicht

[Luke]

I’m thinking up a new animation system for Irrlicht,

The animation system Irrlicht uses now is very limited, and lacks basic features like bone control, and transitions (blend two random frames together)

This new system will not break any old code. Has bone control, transitions, smoother animations (the old problem of an int passed for frames).
It will fix the problem of each loader needing to do the animation it's self. And should be capable of hardware skinning.

This should be able to be as fast or faster then the system used now, the x animator that most people are using now is pretty slow.

A basic design of what I’m thinking:



I know this will work because I’m using a system very simpler to this in my game, ‘Ant conflict’

Let me know what you think, if you can see any problems, future problems, missing features, etc.

[xhrit]

I think if it works in linux then you should go for it. Just make sure you keep writing documentation after you finish.

[sio2]

Looks good. Your Ant Conflict demo shows you know what your doing.

I think I may hold off on finishing my Doom3 Model loader until you've done this.

[Spintz]

I think if it works in linux then you should go for it. Just make sure you keep writing documentation after you finish.

F Linux. Too much attention is paid to Linux/OpenGL as it is. Make it work for everything( which there's no reason why any of this would be driver or OS specific, but just to argue )...

[rogerborg]

Looks good. When you say that it won't break any existing code, do you propose leaving the current (horrible) file-format-specific implementation in place as well as introducing a sane system? If so, would the file loaders produce new animation data in addition to the existing file-format-specific data, or do you envision switching over to the new system internally, and having the existing file-format-specific APIs operate on it?

[Luke]

Yeah, no reason it won’t work in Linux,

When you say that it won't break any existing code, do you propose leaving the current (horrible) file-format-specific implementation in place as well as introducing a sane system?

Well I’m planing on adding a sane system, then slowly removing the horrible file-format-specific implementation (moving it over), the whole time this can be transparent to the user.

I can not break any code, and change the file-format-specific implementation at the same time

If so, would the file loaders produce new animation data in addition to the existing file-format-specific data,

The loaders would store a slightly different animation data but very similar to how it is stored now, but not addition to the old data (no need)

or do you envision switching over to the new system internally, and having the existing file-format-specific APIs operate on it?

The skinnedMesh will wrap the existing file-format-specific APIs, while it is only developing, (some commands will stay file-format-specific, but there are none that are commonly used)

then the skinnedMesh will completely handle the animating when complete. This change can be made bit by bit, or one format at a time, there is no big jump.

[xskinyx]

i think your graph needs a key.

[Saturn]

xskinyx: This is a static UML class diagram, for a reference see here: http://tnerual.eriogerg.free.fr/umlqrc.pdf

Luke, this looks very good and I like your proposed approach for the transition from what is in irrlicht now and what when you're done.

Personally, I'd work out more classes, like Skeleton instead of mixing it into SkinnedMesh, but your interface fits better with irrlicht's interface in that regard.

Any planned changes regarding animations? For instance do many file formats support named animations. Do you plan to allow access to animations by name too?

[zeno60]

Um, yeah ... I'm gonna need you to have this finished by saaaturdaaay...

[/office space quote joke]

[Luke]

Personally, I'd work out more classes, like Skeleton instead of mixing it into SkinnedMesh, but your interface fits better with irrlicht's interface in that regard.

Yeah, but I cannot see any advantage in doing that, and as well as the small slowdown from it, it complicates the code.

I know ogre uses a skeleton class, but it doesn’t seem to have any advantage, and makes it harder to use.

For instance do many file formats support named animations. Do you plan to allow access to animations by name too?

Well I think the frame based animation is fine, I know b3d as no named animations, I don’t think ms3d does, but x does.

for access to animations by name, if needed, could simply be converting from the name to a frame range internally.

Um, yeah ... I'm gonna need you to have this finished by saaaturdaaay...

Saturday, what? Noo, half the day is over already, I better get to work…

[buhatkj]

cant honestly say i fully got all that, or even tried, but the features sound useful. i love youd demo, so i can see how powerful this could be.
good luck!!

[vermeer]

I vote for the "made by luke" stuff...No matter if I don't get an idea of what you'r talking about...

(and also the md5 plugin of sio,too ... b3d and md5 are my favourite character formats these days.. )

Actually, for an artist, seems an improval of what can be accessed by code in irrlicht of the rigged character...

[Saturn]

Personally, I'd work out more classes, like Skeleton instead of mixing it into SkinnedMesh, but your interface fits better with irrlicht's interface in that regard.

Yeah, but I cannot see any advantage in doing that, and as well as the small slowdown from it, it complicates the code.

I know ogre uses a skeleton class, but it doesn’t seem to have any advantage, and makes it harder to use.

The advantage is, that you can share skeletons over meshes. It is not uncommon for current games, that all meshes share a (few) common skeleton(s) with all animations. And the meshes/entities only have their current joint state stored instead of all the animations anew. This sums up to a lot for larger scenes.

I'm not saying you should make the distinction. But it is not true, that there is no advantage.

[Luke]

The advantage is, that you can share skeletons over meshes. It is not uncommon for current games, that all meshes share a (few) common skeleton(s) with all animations.

Well all the nodes/entities of the same mesh will be sharing the same skeletons, just not with different meshes. I might lose 300kb with large meshes, but it’s faster, and the interface is *much* simpler.

And the meshes/entities only have their current joint state stored instead of all the animations anew.

The nodes/entities will have their joint state stored with this new method. I'm not sure how well you can see it by the UML, but IjointSceneNode is stored in AnimatedMeshSceneNode (this is optional at runtime by the way)

This sums up to a lot for larger scenes.

The only advantage I can see is a few kbs of ram, which is nothing compared to the textures.

[Saturn]

300kb? Quite a bit more actually. In a project I currently work on, skeleton and animation data amount to > 3MB in memory data per skeleton. Mainly because of the many animations, especially transitions and fighting anims. We have only a few different skeletons, but a large number of models. Even though technically not all models need all animations, it is much handier for our artists this way. When there are 12 models with the same skeleton in the scene, you'd save more than 33MB. Also I don't see why this would be slower. The single level of indirection added? This is more than outweighted by the cache friendliness of a shared skeleton.

So again: You're doing the improvements to irrlicht and thus a huge favor to the community and it is much appreciated. And I'm just talking.

All I want is to not let the IMHO wrong numbers stand uncommented. Having a separate skeleton has its advantages (another one is, that you could, in a next step, allow to share multiple meshes to attach to a single joint state set (or however one wants to call it)).

But you are completely right, that with your implementation the API stays simpler, which is more important for irrlicht.