Hello, I bring greetings from 2D land, but I have ventured here to the realm of 3D to learn your ways, but they are strange to me and I seek guidance.
Seriously though, I'm trying to get started and there is a lot to take in. I've been going through the tutorials and I think I am developing a decent understanding of how things work.
What I want to do is separate the animation data from the model, and I haven't been able find any information on how to do this. So far everything I have seen works on the principle that the animation data is part of the model's file. This approach doesn't make sense to me because I would expect that you could have a file that contains a 'Run' animation that can be applied to any humanoid model. The idea is that when you want to add a new animation you create one file with the animation data, then mix and match that with the models you want to have the new animation.
I know that such a thing is possible because Second Life's system is capable of it. I do not know if Irrlicht supports it. So Is such a thing possible with Irrlicht, and if so could some one point me to some resources on the subject?
I am overwhelmed! (Separating Animation from Models)
Problem here is, that there really is no animation system in irrlicht. Each file type implements the IAnimatedMesh interface itself and hides the internal animation structure.
If you want to do this, you have to either only use only a single file type and modify the loader of this type (for instance .X) to your needs. Or you abstract the animation system out of the loaders into proper backend classes. (Skeleton, Bone, Animation, KeyFrame, etc..)
Then you have the basis to add animations from other sources too.
Last solution is preferred of course, but more work intensive. Though both are in no way easy and fun.
If you want to do this, you have to either only use only a single file type and modify the loader of this type (for instance .X) to your needs. Or you abstract the animation system out of the loaders into proper backend classes. (Skeleton, Bone, Animation, KeyFrame, etc..)
Then you have the basis to add animations from other sources too.
Last solution is preferred of course, but more work intensive. Though both are in no way easy and fun.
-
rogerborg
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
It's worse than animation; there shouldn't be any IFooMesh interfaces at all, just a single IMesh and IAnimatedMesh, with separate loaders for all the file types. Irrlicht's IFooMesh kludge is appallling; it works, it's relatively easy to copy-and-paste in a new file type (and integrated loaded) but it's just oh so very, very wrong.
@zangetsu -
There's no reason you couldn't do this with Irrlicht - the mesh interface certainly allows for it. However you are correct, with the current mesh loaders, the animation data is loaded along with the model. You would need to write a custom loader to share an animation track across models.
Another thing to keep in mind, is that the skeleton of each model would have to be similar for them to share animations. Even then, it is likely you would want the actual animations to be slightly (or completely) different for each model. Think WoW, where each model has the same tracks (ex: /em dance) but they are implemented completely differently.
@Saturn and @rogerborg -
I have to disagree. Irrlicht's approach to animation is very sensible and flexible. Conceptually, an animated mesh is a mesh where the appearance varies over time (the frame number). That's it. It is a strength that there is no embedded assumption about the animation structure - the details of skeletal or not, joint vs bone, etc. are correctly left to the implementation, where it belongs (I'm no expert on 3D animation, but I've read enough to understand there are several different ways to approach it). It could benefit from addition of an IJointAnimatedMesh to unify MS3D, DX and B3D, but that's about it. But the advantage is that MD2 and Lightwave can fit into the existing design.
There's no reason you couldn't do this with Irrlicht - the mesh interface certainly allows for it. However you are correct, with the current mesh loaders, the animation data is loaded along with the model. You would need to write a custom loader to share an animation track across models.
Another thing to keep in mind, is that the skeleton of each model would have to be similar for them to share animations. Even then, it is likely you would want the actual animations to be slightly (or completely) different for each model. Think WoW, where each model has the same tracks (ex: /em dance) but they are implemented completely differently.
@Saturn and @rogerborg -
I have to disagree. Irrlicht's approach to animation is very sensible and flexible. Conceptually, an animated mesh is a mesh where the appearance varies over time (the frame number). That's it. It is a strength that there is no embedded assumption about the animation structure - the details of skeletal or not, joint vs bone, etc. are correctly left to the implementation, where it belongs (I'm no expert on 3D animation, but I've read enough to understand there are several different ways to approach it). It could benefit from addition of an IJointAnimatedMesh to unify MS3D, DX and B3D, but that's about it. But the advantage is that MD2 and Lightwave can fit into the existing design.
ssexton, there are not that many different animation types. Skeletal animation, morph target animation and relative vertex transforms. I don't know of any other. There is no reason why different animation types prevent you from abstracting animations out of the loaders. See for instance Ogre's approach.
The irrlicht approach is not sensible for a number of reasons. Huge amounts of duplicated code. If you want to change an aspect in irrlicht regarding animations, you have to change it in all these classes seperately. Introduction of bugs this way is almost guaranteed.
Also as it is, you cannot create animations at runtime. Or control parts of the skeleton manually. If the loaders had to just create Skeletons, Bones, Animations, etc, you'd have to have an API for animation creation anyway.
ssexton, and what is sensible about having different bone access functions for each type, which basically do all the same. getXBone, getMS3DBone, etc.. is downright stupid. I understand that it just grew with time. But it has nothing to do with sensibility and flexibility.
The irrlicht approach is not sensible for a number of reasons. Huge amounts of duplicated code. If you want to change an aspect in irrlicht regarding animations, you have to change it in all these classes seperately. Introduction of bugs this way is almost guaranteed.
Also as it is, you cannot create animations at runtime. Or control parts of the skeleton manually. If the loaders had to just create Skeletons, Bones, Animations, etc, you'd have to have an API for animation creation anyway.
ssexton, and what is sensible about having different bone access functions for each type, which basically do all the same. getXBone, getMS3DBone, etc.. is downright stupid. I understand that it just grew with time. But it has nothing to do with sensibility and flexibility.
Well That explains that. I just wanted to try and make things easier for the artists (by admission that would have been myself when starting). But thinking about it having a standard set of bones, with a standard set of animations. could be artistically limiting. This is basically what Second Life has, but when I think about it there are a great deal of hacks that people have to use to do something that could have been pretty basic. I think I am going to have to give my design some more thought.
@ssecton - while you are right about custom loaders, that would probably entail something I am not prepared to tackle. I'm a fairly competent .Net programmer, but I have a feeling for it to be worth while I would want to write it C++, so that it could become part of the library. Plus I would then need to expose it to .Net. This is simply something I am not able or willing to undertake.
So my choices are to reconsider what I want to do, or possibly find another library (which I don't expect to find something better that offers .Net support.)
@ssecton - while you are right about custom loaders, that would probably entail something I am not prepared to tackle. I'm a fairly competent .Net programmer, but I have a feeling for it to be worth while I would want to write it C++, so that it could become part of the library. Plus I would then need to expose it to .Net. This is simply something I am not able or willing to undertake.
So my choices are to reconsider what I want to do, or possibly find another library (which I don't expect to find something better that offers .Net support.)
-
monkeycracks
- Posts: 1029
- Joined: Thu Apr 06, 2006 12:45 am
- Location: Tennesee, USA
- Contact:
I would think that would be possible as you can time the frame passes and you can select which frame you want to be currently shown and then it shouldn't be too hard to work out which frame should be shown based on the elapsed time. But i'm not sure why you'd want to do that as Irrlicht does that for you anyway when it runs the animations!
