Mecanim could really work with props better. Say a character throws the ball.
Set file to humanoid for character - this breaks the ball translation /rotation keys
Set to generic for Ball - this breaks mecanim
Do I really need two files, synced, to have the ball thrown by the character? Two state machines, two files, 2x code commands? For a ball?
Am I missing something here?
Legacy:1
Mecanim:0
Maybe I don’t understand what you’re asking, but why is this an animation issue? Couldn’t you parent the ball (a simple GameObject) to the character’s hand? When the “let go of ball” animation event occurs, deactivate the simple GameObject ball, and instantiate a rigidbody-controlled ball in its position with a certain force.
Well thats an example for simplification purposes. What I’m really talking about is a needle, that is poked through a blanket, released, then pulled through from the other side. Its a standalone object with its own translation and rotation keyframes. Not parented. And mecanim doesn’t seem to be able to handle that.
For arguments sake consider the ball has to be thrown exactly where it needs to be thrown, eg Keyframed in its own right.
That requires a whole seperate file, and the headache of syncing, scripting both, a second state machine etc.
this could apply to numerous props that need their own keyframes.
Stuff that the “legacy” system handles easily.
True. I guess that’s the price of adding all the new features that Mecanim provides.
Just export them separately. (Selected in export options.) Or make them a single animation if they are used together. I’m not sure I understand what you are trying to accomplish here. A controller handles a single “animation”. (Whether is a whole room full things animating or a bouncy icon.). If you have independent animations you want under one controller, you can just build an overly complex controller with every combo, but that is ugly. Just make two separate ones. It’s only a couple of clicks.
I know you said ball was just an example, but not practical one, as you would really ever do it that way. If the ball Is keyed, and whatever is throwing is keyed, then you only need one animation/controller. . More than likely it be thrown programmatically.
Can be more specific about what you are trying to do?
Ok so example at hand was sewing with a needle.
The needle is positioned using a constraint, so is not parented to fingers. (The position constraint information was baked to keyframe data, and the rotations were hand keyed on top of that.)
It has its own keyframes, standalone.
It actually did work after I made these posts when used as a generic animation, but setting it up as humanoid, after quite a bit of repeating the same sort of things in the pipeline, the best I could get was the mecanim system approximating the character animation so the accuracy was gone. The needle did its thing, with keyframes, about an inch away from the fingers due to mecanim degrading the animation data. It the needle was still parented, it would have still resulted in the needle not being in quite the right place. And honestly half the time when using humanoid the needles keyframes were just totally ignored, it seemed a fluke to get them to work, albeit with a one-inch offset from where it was supposed to be.
I did ask if I was missing something here and in the end It seems that its that if you have good animation on the right character already you can just use generic animation types. Humanoid only seems of value if you need to retarget, and don’t mind the accuracy errors.
I don’t fully understand why the humanoid for the first 9 tries out of 10 wouldn’t read and play the prop rotation translation keyframes, but that was my experience.