^This is the same file duplicated in Unity with the respective settings for animation type as indicated. Humanoid and Generic both fail to deliver this time… Anyone have any ideas at all on why my works getting screwed like this?
I may have to just go with legacy animation on this particular job but its not a good look for me or Unity, and its not really what the client wants either. Trying to wrangle these issues mid-project is not financially sustainable for my business, that’s for sure.
Note: The animation was created on exactly this model. There’s no retargeting, this is all native animation on the model that you see. So the error is in no way due to retargeting. So frustrating!
I would love to hear your suggestions for fixing this before I write mecanim off completely…
Hey Aaron - Thanks for the laugh about your avatar.
I can feel your frustrations about dealing with tech ‘oddities’ - especially when developing something for a client.
I do not have a solution to the issue you are showing, with the workflow you are using, but I can relate and I’m curious about your workflow.
Personally I think using mocap to control props leads to - stuff like you are seeing on screen. I’ve experienced similar issues with mocap that is extended beyond the base human hierarchy, stuff starts to fall apart and weird anomalies just happen.
I understand contract work so I’m not suggesting you modify your workflow, but if this was work I was doing for myself I would control all props by hand. Definitely not have them in the mocap hierarchy. Have markers on the logs be parents for the 3D log models, parent the models in Unity, and allow the markers to position the models, but control the rotation/orientation by hand. This overcomes relying on the mocap to work as expected when using props.
Oddly it looks like the rotation matrix is being either damped or multiplied on the props. And its weird, you are right, mecanim is the culprit. I’m guessing this has something to do with how the layer mask for the props is setup. Not sure - just a guess.
It’s weird generic doesn’t work as expected.
This is interesting - why does it matter to your client if it’s legacy or mecanim as long as the task gets done? That animation looks like a one-off not a cycle so legacy or mecanim shouldn’t really matter. I’m guessing they already have a pipeline setup and are wanting to feed it with compatible mecanim animations.
The plan is/was to make a template that could be reusable. Potentially with Mecanim I think we can swap out just the player character and the whole state machine and animations should be reusable. So instead of all characters using humanoid and mecanim for this purpose, I’m winding up with a mismatch of humanoid, generic and now legacy solutions… which for reusability is inconsistent, kind of messy and a little embarrassing.
You make a point though, in a way. I can look at using constraints and baking trans/rot info into the pieces of wood rather than parenting. Oddly enough due to problems introduced using this technique in the last character it was suggested I go down the parenting route lol. You just can’t win sometimes. It will still rule out humanoid though because that seems to introduce innaccuracies with rigs, meaning extremities don’t end up being where they are supposed to be in 3d space. Bits of wood will end up levitating etc instead of being “held” in hand.
No problem. Hope you find a sturdy character workflow you can count on and move forward with.
And thanks for understanding what I was talking about and using the proper terminology.
