Fixed incorrect blending in Pos/Rot/Scl Track

[TokageItLab]

Fixed #54407.
Fixed #55838.

Follow up of #53689. The process of if (t->process_pass ! = process_pass) needs to be separated between the root motion and others.

Before:

2021-10-25.6.48.51-1.mov

After:

2021-10-25.6.44.44-1.mov

[TokageItLab]

Okay, I checked the second video again and found that the rotation was broken, but I fixed it. It needed to include #53903 because it breaks the rotation.

2021-10-25.7.41.22-1.mov

[TokageItLab]

#53903 fixes inconsistent rotation blending order, but does not fix additive blending correctly, and more fixes is needed to get the animations to add correctly in NodeAdd2.

For now, this PR will fix the inconsistent rotation order and fix the bug that causes weird blending.

[TokageItLab]

I think this PR is reviewable, but it doesn't solve the triangle nonlinear blending problem that marstaik mentioned in #34134, also this comment problem is don't so. They are already broken in master, regardless of this PR, and I feel that some overhauls of the blending algorithm is needed.

In order to implement NodeAdd2 and NodeSub2 (BaseAnimation extraction) correctly, I think the quaternion process needs to be changed as needed. At least marstaik's PR was consistent in the order of calculation of rotations, with fix for additive blending as side effect, but still no effect for position and scale. My misunderstanding. However, there is a Quaternion problem.

Probably the fundamental reason why the blend order is broken is that the number of times the blend value is multiplied in AnimationNode::_blend_node() is wrong or the if (t->process_pass != process_pass) check is working in an unintended way when NodeBlend is chained. Also, for NodeBlend2D triangles, it may be necessary to change the way the blend weight is calculated. This PR won't fix them, but it will at least address the regressions that are happening now.

[nonunknown]

I can confirm that this PR fixed the issue!

Before:

animrot.mp4

After:

fixed.mp4

[TokageItLab]

@reduz Here is a summary of what this PR is meant to do.

The initial Transform3D value of the blend is different for root motion and non-root motion.

• For root motion, only the difference between the previous and next frames is needed, so all values are default values such as translate = Vector3(0,0,0), rotate = Quaternion(0,0,0,1) and scale = Vector3(1,1,1)
• For non-root motion, the initial value is the current playback position value of the animation which found first by iterator

Due to the PR in #53689, the initial values of all the blend animations were wrongly set to the same as the root motion; In other words, it never set the key correctly after the decision that it is not the root motion. As a result, the current blend is broken. This PR fixes it.

[NoFr1ends]

This also fixes the xfade time in the state machine for me.

[TokageItLab]

This also fixes the xfade time in the state machine for me.

That may be a side effect of removing rot_blend_accum. However, there is still inconsistency in the chained blends, so we need to fix that after this PR is merged.

[AThousandShips]

The current solution breaks root motion by initializing scale to zero except for tracks with scale

[TokageItLab]

@AThousandShips Are you talking about 4.0? That probably won't fix this bug. It is caused by a wrong initialization method other blends than root motion, so we need to implement the correct initialization method.

[AThousandShips]

@TokageItLab sorry meant this PR breaks root motion compared to the unchanged code, but correcting initialization seems necessary, thank you for clearing up it was noticed

[TokageItLab]

@AThousandShips Can you send a test project or video for root motion? If this PR breaks the root motion then it needs to be fixed.

[TokageItLab]

@AThousandShips Ah sure, I confirmed that it breaks, the root motion needs to initialize all the TRS values, so the previous initialization method seems correct for the root motion.
Thanks for the nice pick! I've fixed it now, please check if it works correctly.

[AThousandShips]

@TokageItLab going over the updates and that's the solution I arrived at in my own usage of this PR before I joined, so I can confirm it has worked in my own usage, not familiar with the rest of the animation system but this appears to fix the blend issue while keeping root motion correct
Thank you!

[fire]

Is this ready? I'll kindly ask the relevant people.

[TokageItLab]

It has been ready!

[TokageItLab]

This fix is included in #56902, but I guess a lot of users are having trouble with this issue, so if you need an immediate fix, you can merge this PR. I'll leave it open for now. If #56902 is merged earlier, this PR will be closed.

[TokageItLab]

Pending; possibly, could be resolved in a more correct way by eliminating lerp() with reference to #46038 (comment).

[TokageItLab]

#46038 (comment) has a problem in Quaternion, I don't know if that's the problem reduz was saying in #34134 (comment), but I think we need to brush it up. Re-ready this once.

[TokageItLab]

I sent another solution #57675, it solve blend order inconsistency. I keep this PR open, but I suggest that #57675 should be the priority and if #57675 is merged earlier, this PR will be closed.

[TokageItLab]

Since #57675 is more stable now, this PR seems no longer necessary.