Role of bones in animating models
-
onionguy92
- Posts: 107
- Joined: Sat Dec 02, 2006 10:47 pm
- Location: The Northern State of the Continental US
Role of bones in animating models
Alright, everything I've seen says the secret to animating models is bones bones bones. I created my bison model, and fitted it with bones. Some of them stuck out a bit. I got my poses for the model converter animator thing. I loaded them up, and lo and behold, the converter yells at me. It says the number of faces is changing from frame to frame. Could this have something to do with the bones sticking out?
As in my other post.. don't think about skeletons and animating until you've got the mapping sorted out. You'll only have to redo it otherwise.
The secret to animating some models is bones bones bones. This is also a bit of an involved subject, so bear with me (luckily I seem to be in typing mode tonight).
Right, using Gmax to make stuff for TU, you've got two basic options for animation.
1. Using transforms and keyframes.
By "transform" I simply mean, moving stuff around, rotating it or scaling it. I hope you know what a keyframe is if you've been playing with animation already ;). So, as an example: you have a box model at 0,0,0 on keyframe 1. That's its starting state. You click the Animate button, advance to keyframe 6 (using the slider at the bottom of the screen), then move the box somewhere else. Turn off animate, put the sllider back to its start position, press the play button: box moves from start to finish. If you export each frame and then recombine them in the Model Converter, you have a simple animation. No bones.
2. Using skeletons (bones) and the Skin modifier.
You could use this method to do the above animation, but it'd be a very long way round a simple problem for a box moving from A to B. But, bones/Skin is pretty much essential for anything organic... including, yes, your bison. It sounds like you're most of the way there with this one. To answer your question, no, it has nothing to do with the bones sticking out. It's often important to have them sticking out a bit, so the skin modifier works properly with all the vertices in the model.
What it probably has to do with is not having rigid vertices turned on (I think it's in the Skin modifier's Advanced Params tab, or something). Hard to explain concisely, but.. when you're using Skin and vertices aren't rigid, then Gmax will sometimes combine vertices when movement of the bones deforms the mesh. It's an effect that's useful in modelling and animating complex/realistic musculature, for when stuff folds properly and so on (muscles sliding over other muscles, cloth folding in on itself, stuff like that). And you'll probably see some of that stuff in "proper" games that have "proper" skeletal animation systems.
However, we don't have that. We have a vertex animation system, so we can't do anything clever with deformable vertices. All we can do is move a vertex from one place to another place in a straight line. In order to do that, the vertex numbers (and correspondingly, the face numbers) must remain the same from frame to frame in the Model Converter. By checking "rigid vertices" you should be able to make that happen. Gmax won't change vertex orders and all that funky stuff when it deforms a mesh with bones.
Longish explanation - as in the other post, probably more of a pointer for your own research than a comprehensive reply... but I hope that helped.
f
The secret to animating some models is bones bones bones. This is also a bit of an involved subject, so bear with me (luckily I seem to be in typing mode tonight).
Right, using Gmax to make stuff for TU, you've got two basic options for animation.
1. Using transforms and keyframes.
By "transform" I simply mean, moving stuff around, rotating it or scaling it. I hope you know what a keyframe is if you've been playing with animation already ;). So, as an example: you have a box model at 0,0,0 on keyframe 1. That's its starting state. You click the Animate button, advance to keyframe 6 (using the slider at the bottom of the screen), then move the box somewhere else. Turn off animate, put the sllider back to its start position, press the play button: box moves from start to finish. If you export each frame and then recombine them in the Model Converter, you have a simple animation. No bones.
2. Using skeletons (bones) and the Skin modifier.
You could use this method to do the above animation, but it'd be a very long way round a simple problem for a box moving from A to B. But, bones/Skin is pretty much essential for anything organic... including, yes, your bison. It sounds like you're most of the way there with this one. To answer your question, no, it has nothing to do with the bones sticking out. It's often important to have them sticking out a bit, so the skin modifier works properly with all the vertices in the model.
What it probably has to do with is not having rigid vertices turned on (I think it's in the Skin modifier's Advanced Params tab, or something). Hard to explain concisely, but.. when you're using Skin and vertices aren't rigid, then Gmax will sometimes combine vertices when movement of the bones deforms the mesh. It's an effect that's useful in modelling and animating complex/realistic musculature, for when stuff folds properly and so on (muscles sliding over other muscles, cloth folding in on itself, stuff like that). And you'll probably see some of that stuff in "proper" games that have "proper" skeletal animation systems.
However, we don't have that. We have a vertex animation system, so we can't do anything clever with deformable vertices. All we can do is move a vertex from one place to another place in a straight line. In order to do that, the vertex numbers (and correspondingly, the face numbers) must remain the same from frame to frame in the Model Converter. By checking "rigid vertices" you should be able to make that happen. Gmax won't change vertex orders and all that funky stuff when it deforms a mesh with bones.
Longish explanation - as in the other post, probably more of a pointer for your own research than a comprehensive reply... but I hope that helped.
f