Separating vertex based animations and bone based animations

[r2d2]

Ok, so here are some ideas i have thought of. First of all i think, that it is really needed to separate vertex based animations and bone based animations. Trying to fit both into one interface would create a huge overhead.
Vertex based animations (will be called VBA during the following text) mainly suffer from the fact that they are not reuseable. You have to recreate the animation for every single mesh you create. This is a whole lot of work. Apart from this you can't easily share animations between models, you can't simply modify the proportions of the models, etc.
When using bone based animations (will be called BBA during the following text) meshes which share the same skeletons may share animations, you can reuse animations and easily add new animations to several models you don't have to redo every single model if you need a new victory dance animation. You also can modify the proportions of your models by simply modifing the lengths of the bones. You won't need thousands of meshes to make things look different you can just change the proportions. (Some more features which can be mentioned: blending of different animations [eg. one for the feet, one for the mount, the eyes, ...]. Sure you could also do that with VBAs but if you take into account the exchangeability of animations into account, this feature really is great and in case of VBAs it could cause troubles and is normally harder to accomplish).

Looking at this short and quick summary you can already tell that the functions needed to handle VBAs and BBAs share some common things but also have severe differences. BBAs need functions for adding animations, modifying bone lengths, comparing skeletons and more. These functions are not needed by VBAs. They just would create a huge overhead. Also if you combine both into one interface and use both VBAs and BBAs during your project you might cause problems because of accidentialy using BBAs functions while having loaded a VBA (sure this is not a very important point but i think it has to be considered).

These were basically my main points why i would suggest that BBAs and VBAs should be separated. What do you think about it? What does the dev team think about it?

How should they be separated? That's something i am not so sure about cause i don't know how exactly the dev team wants Irrlicht to work.

Possibility 1: create two separate AnimatedSceneNodes, one which takes care of the VBAs and one which takes care of the BBAs. This way you could directly use the AnimatedSceneNodeBBA to get the animations and such and modify the bonelengths of just this specific SceneNode, not every SceneNode which uses this anim/mesh.

Possibility 2: Stick to the current AnimatedSceneNode and extend it. Use getAnimation and getMesh functions to retrieve animations and meshes (and analogously set them). You to modify bonelengths and blend animations you would have to extend the AnimatedSceneNode and create a certain overhead when using VBAs cause they don't need these functions.

These are the two possibilitys i think are the best currently. I would prefer the first one, cause it separates the VBAs and BBAs in a clear way. Feel free to suggest other possibilitys.

[hybrid]

I must admit that a few things are shared in the current implementations, but bone-based animations use CSkinnedMesh, while vertex-based is kept in the methods from CAnimatedMesh, quite often separated by (if SkinnedMesh)...
Which parts of the current CSkinnedMesh would you define as improper?

[r2d2]

It is ok to separate the different mesh types from each other and thats perfectly fine having a CSkinnedMesh and all the other CMesh classes.

I would completely rewrite the CSkinnedMesh as it uses an old bone animation format. A vertex can only be affected by one bone/joint (i think that has been discussed in the MD5 Loader thread). Then you should separate the animations from the CSkinnedMesh class and make them an own class CBoneAnimation or sthg like that. On the one hand just because it's OOP (the Mesh and the Animation are simply two completely different things [in case of BBAs, if you use VBAs you can't separate them that's for sure]). On the other because it makes thing more clear (especially when you want to share animations between AnimatedSceneNodes, blend animations together, etc.).

Why should one introduce two different AnimatedSceneNodes? Because VBAs and BBAs work in a completely different way and have completely different features. Using VBAs the one and only thing you can do to make SceneNodes which share the same mesh look different is using different textures. Using BBAs you can also adjust the different bone lengths. This can be used to make chars really look different, change the shape of faces, and such things become possible! It's something most modern MMOs use (but i am not sure how they implement it, using bones is definitely one possible way). You can have a look at this video. It shows the age of conan char creation. You can change the body of your char to look more muscular, thin or big. That could be achieved by altering bone lengths. But to achieve this effect on a per character basis you have to do change bone lengths on a per SceneNode basis. If you would change the bone lengths on a per mesh basis (which we share between different SceneNodes) all SceneNodes will look the same.
Another great feature of BBAs is that you can easily attach other scene nodes to a certain bone so it will also get affected by the bone's rotation and such. This would also need new functions which won't be used by VBAs.

When using BBAs you can share animations between models and only have to add the animations you really need to a specific SceneNode. And you should be able to set these animations by setAnimation(s32 id) or setAnimation(string name). Using frameranges really is improper cause every single SceneNode may have a different amount of animations and the different animations would be mapped to different frameranges (sure you could try introducing a standard mapping but if you want to use different walk animations (just the walk anims should differ, the number of frames should differ) for your zombie1 and zombie2 you will run into troubles. Using named animations would solve this problem.

That's why i think that combining BBAs and VBAs into one AnimatedMeshSceneNode is not the right way to go.

[sio2]

A vertex can only be affected by one bone/joint (i think that has been discussed in the MD5 Loader thread).

WTF? If that's correct then that's pretty poor IMHO.

Are you sure that that's not just the base functionality? Surely the code supports / can be extended to up to four weights per vertex?

[hybrid]

AFAIK, a vertex can be affected by an arbitrary number of bones and weights.

[r2d2]

I am not sure if you perhapts misunderstood me, especially this sentences:

I would completely rewrite the CSkinnedMesh as it uses an old bone animation format. A vertex can only be affected by one bone/joint (i think that has been discussed in the MD5 Loader thread)

The second one is directly related to the first one. In the current implementation one vertex can only be affected by one bone/joint. At least as far is i understood the code.

And i just noticed that i really misunderstood the code. These are lines 490 and following from CSkinnedMesh.cpp

Code: Select all

			if (! (*(weight.Moved)) )
			{
				*(weight.Moved) = true;

				buffersUsed[weight.buffer_id]->getVertex(weight.vertex_id)->Pos = thisVertexMove * weight.strength;

				if (AnimateNormals)
					buffersUsed[weight.buffer_id]->getVertex(weight.vertex_id)->Normal = thisNormalMove * weight.strength;

				//*(weight._Pos) = thisVertexMove * weight.strength;
			}
			else
			{
				buffersUsed[weight.buffer_id]->getVertex(weight.vertex_id)->Pos += thisVertexMove * weight.strength;

				if (AnimateNormals)
					buffersUsed[weight.buffer_id]->getVertex(weight.vertex_id)->Normal += thisNormalMove * weight.strength;

				//*(weight._Pos) += thisVertexMove * weight.strength;
			}

I totally misunderstood that if/else statement and the way weight.vertex_id was used. Damn it ^^ Sorry guys about that. (Perhaps we should create some docs for the SkinnedMesh class fur dumbasses like me )

But there is still the point with the animations and changing the length of the bones on a per node basis and not a per Mesh basis, the blending stuff and attaching something to a certain bone of a bone animated scene node.

[Steel Style]

So you barely suggesting creating class for Animation. So "walk" will be an type entity of this class and every mesh will be able to support multiples animation with the possibility to blend the assigned animation.

I would say that should be interesting but I have one question about BBA. Mesh indices should be disposed the same way for every mesh I'm write ?

[Nadro]

I think, that before add any changes to animation system, we should at first resolve vertex type problem, because animation system is very depend on vertex structure.

[hybrid]

I think, that before add any changes to animation system, we should at first resolve vertex type problem, because animation system is very depend on vertex structure.

No, unless the vertex types cannot handle this transparently, there won't be much use in the new vertex types anyway. These are definitely to completely separate problems. The only relation might come in when hw skinning is used, but that's the problem of the folks that write the hw skinning...

[r2d2]

@Steel Style: i am suggesting creating a class for bone based animations and a new scenenode which is specialised on bone based animations. If you use vertex animated models (e.g. MD2 ones) you won't be able to separate the animations from the model.

Sure the index buffer will disposed the same way as in every mesh implementation. Is there a certain reason why you ask this?

@Nadro: animating a model is completly separate from the vertex structure. It doesn't matter how the vertex structure looks like, all the calculations will stay the same. The only thing is that you will save your final result to a different structure. So we can discuss both things simultaneously. Whether you save the book you have written is not a part of the book or the writing of that book itself it is a matter of representation, how you want it to look like and such. That's not as important as the writing of the book itself. That's something you can take care of after you have written the book.

[hybrid]

I totally misunderstood that if/else statement and the way weight.vertex_id was used. Damn it ^^ Sorry guys about that. (Perhaps we should create some docs for the SkinnedMesh class fur dumbasses like me )

But there is still the point with the animations and changing the length of the bones on a per node basis and not a per Mesh basis, the blending stuff and attaching something to a certain bone of a bone animated scene node.

Documentation of the implementation details has very low priority, since most people won't have to deal with it. But maybe you can now understand why I was very puzzled about your idea to completely rewrite everything. Most stuff is already in the current class. You can, e.g., clone the mesh in order to change bones on a per node basis, blending two animations is also possible, and attaching to a bone or using a different animation from a separate mesh is also possible. The interface might not be optimal, but that's easier to fix than rewriting the whole system.

[bitplane]

Ok, so here are some ideas i have thought of. First of all i think, that it is really needed to separate vertex based animations and bone based animations. Trying to fit both into one interface would create a huge overhead.

I agree that we need a unified format for tweened animations, there are lots of formats that aren't supported and to support them would mean copying MD3 or MD2 and rewriting.

MD2 should probably not be merged with this format though, because it's really minimal and will (should) work on mobile platforms.