Early video games have many animations, producing such amount of animations need a flexible animation pipeline and a flexible pipeline needs a flexible working package. Here is when 3dsmax Character Studio comes in. Character studio is such a flexible animation package, it can help animators to create animations as fast as they can, it's like a plug and play device, but it has some limitations such as zero degree of extendability, this means it has low level of customization but it's still a good package. The most annoying problem it has, is that it's a huge black box. It doesn't work in the way 3dsmax works. It was a standalone plugin on older versions of max but now it becomes an inseparable part of 3dsmax.
On this post i'm gonna talk about the weird hierarchy of character studio and the problems it can make on relatime animations in another environment such as your game engine.
For all who worked with character studio they know that if they rotate the "Bip001 Spine", "Bip001 Spine1" and it's children are going to rotate. it's natural because you find that they are it's children they have to move you can see it's structure in the picture below.
But there are some other unyielding children which they never obey their parent. So let's take a look at actual hierarchy of a biped using 3dsmax schematic view.
You can see that "Bip001 L Thigh" and "Bip001 R Thigh" are the children of the "Bip001 Spine", but when you rotate the "Bip001 Spine" you see no effects to legs!! That's weird! Character studio internally handles the transformation of the bones not in the way max handles the standard nodes in it's scene graph and more important it's transformation computing is different from an external environments like game engines. Before i talk about the problem and it's solution let me to compare the desired hierarchy and the default one.
From top to down:
1- You expect "Bip001 Prop" to be 'Bip001 Hand' 's child but it's the "Bip001" 's child
2- You expect "Bip001 L Thigh" and "Bip001 L Thigh" to be "Bip001" or "Bip001 Pelvis" 's children but they are the "Bip001 Spine" 's children
3- You expect "Bip001 L Clavicle" and "Bip001 R Clavicle" be "Bip001 Spine3" children but they are the "Bip001 Neck"'s children
You might never find any problem in this kind of hierarchy, because you can see what you expect in max, also there is no problem if you export the animation with normal keyframe sample rate (maybe 30 samples per second or higher) and play it on your game engine because the exporter stores all the transformations at each time step. The main problem occurs when you want to blend between two or more animations with some techniques like partial and additive animations or some procedural animation like inverse kinematics or ragdoll simulations.
Assume a situation in which you have 2 animations, a run and a shoot, if you play each one separately you will see a normal animation, an expected result, but assume that you want a make a shoot while running using partial blending. So you have to make a blend mask for upper body of shoot animation and a blend mask for lower body of run and then playing both animations. When you do that you will see an unexpected result. The legs rotate when you shoot this is because when the upper body animation plays it affects the lower body since originally Bip001 spine is the parent of Bip001 L and R Thighs so when it start rotating it affects the legs. You can find the same problem on the Bip001 Prop bones in the same situation or if you add another animation to the spine or it's children, the prop bone is "Bip001" 's child so it moves whenever Bip001 moves, in this case the additive animation applies to some bones rather than Bip001 so the prop bone inherit no orientation and it leaves the body.
There is a simple solution for this problem. Just do this simple changes on your rig once and for all when you want to start rigging your character it has no side effects and it solves all of the runtime problems:
$'Bip001 prop1'.parent = $'Bip001 R Hand'
$'Bip001 Spine'.parent = $'Bip001'
$'Bip001 L Thigh'.parent = $'Bip001'
$'Bip001 R Thigh'.parent = $'Bip001'
$'Bip001 L Clavicle'.parent = $'Bip001 Spine3'
$'Bip001 R Clavicle'.parent = $'Bip001 Spine3'
Beside of the blending problem, the default hierarchy forces the exporter to export some extra transformation data for translations. So doing this simple changes can help the exporter to optimize the keyframes better and with that you find more memory for your other works.
There is another problem about twist bones hierarchy. Assume that you added some upper arm twists to your rig. By default upper arm twists are children of the clavicle. This leads you to a problem when you want to add some procedural animations at run time on arms like inverse kinematics. If you make upper arm as their parent all the problems at run time will be solved. But there is last remaining problem, and that is max never save your changes to the twist bones hierarchy! so you have to make your custom changes to the twists every time you want to export the animation. I have written a simple callback script for this issue. It is triggered on the open file event. It checks if there are any biped in the scene and and make our desired changes to the twists.
Conclusion
Character studio have a weird hierarchy. This hierarchy leads the animation to some problems while applying procedural animations and blending at runtime. Doing simple changes to it's hierarchy will help you to solve the problems during blending and procedural animations and also helps the exporter to perform a better keyframe optimization.
No comments:
Post a Comment