- Edited
Blending anims messing up instant flipping
I've got a character with legs spread and feet pointed in opposite directions in an idle animation. For the walk animation, the back foot is flipped to face the same direction as the other foot using a scale keyframe with y = -1.0
This works fine, but when transitioning from idle to and from walk, I am seeing the foot do a flip around the Y axis. This makes total sense to me, one animation has the foot at y=1 and the other is y=-1 and so the interpolation between the two animations has to be resolved somehow during the blending.
Is there a better way to achieve what I'm doing here without getting a flip during blending?
I guess you could manually set the scale of the foot when you start the transition. Hard to say if that will sort the problem for you without knowing how your keyframes are set up.
I'm having this issue too. Did you find a solution? I was hoping that the graph of one of the animation would be used for the transition, but it looks like it probably does a linear interpolation anyway.
Mixing at runtime is linear so it will ignore the graph settings. Like I mentioned to Colinday you can set the scale of the foot manually when you start the transition.
Yes, I was looking into this. Unfortunately, since my code knows nothing about the animations that will be played (it's reading from a database and generating the on-screen content), hard coding a scale for a bone prior to transitioning is out of the question.
My next thought was to search the "to" animation's scale timeline for keyframes that don't match the "from" animation's scale timeline and where the graph used is a step graph, preset those bones to the "to" animation's scale. Does this sound reasonable? I've only started digging through the nitty gritty of the runtime to see how feasible/easy it would be to do.
You could do the flip without using a scale key. Eg, have two attachments where one faces the other way. You can use negative scale on the attachment to make it face the other way, you don't need two images.
That sounds much simpler and cleaner than my proposed solution. Thanks, Nate!