Thanks, please keep us updated!

I still hope that we find a way that covers all use cases out of the box, or at least in an easily controllable way. If there is no such solution, we will be happy to implement one of the potential workarounds.

Harald escreveu

Thanks, please keep us updated!

I still hope that we find a way that covers all use cases out of the box, or at least in an easily controllable way. If there is no such solution, we will be happy to implement one of the potential workarounds.

Long time no see, Harald

I just want to report a minor bug in regard to Root Motion.
If the animation clip had the "Separate Translate" box checked, the root motion of the corresponding clip would stop working in Unity Runtime. Not totally system-breaking, but it would improve the work process a lot if this was fixed.

Thanks

Welcome back.

Thanks for reporting, you are absolutely right! I have created an issue ticket here:
https://github.com/EsotericSoftware/spine-runtimes/issues/1997
We will let you know once a bugfix has been released.

This bug has just been fixed on the 4.0 branch, and will soon be merged to the 4.1-beta branch.
A new spine-unity 4.0 unitypackage is available for download here as usual:
Spine Unity Download
Please let us know if this fixes the issue on your end as well. Thanks again for reporting!

The bugfix has been merged to the 4.1-beta branch, a new spine-unity 4.1-beta unitypackage is available as well now.

Harald escreveu

Welcome back.

Thanks for reporting, you are absolutely right! I have created an issue ticket here:
https://github.com/EsotericSoftware/spine-runtimes/issues/1997
We will let you know once a bugfix has been released.

---

This bug has just been fixed on the 4.0 branch, and will soon be merged to the 4.1-beta branch.
A new spine-unity 4.0 unitypackage is available for download here as usual:
Spine Unity Download
Please let us know if this fixes the issue on your end as well. Thanks again for reporting!

---

The bugfix has been merged to the 4.1-beta branch, a new spine-unity 4.1-beta unitypackage is available as well now.

Thanks a lot, Harald, that It works now as expected . Sorry that I didn`t check it out earlier since I thought it would not be under priority considering that it is not a system-breaking bug. :grinteeth:

But now I found another bug that is a bit more bothersome:
When root motion is used with physics2d, the animation will be jittery when colliding against another object with kinematic rigidbody2d. In both the Play View and Scene View, I can observe that the collider stopped as expected, but the animation will keep pushing forward and bouncing back, which looks like a constant vibration. I didn`t notice it before because my animations usually moved relatively slowly, and the amplitude of vibrations seems to be correlated to the speed of the movement, sometimes, it is just too minor and you will have to zoom in to notice it.

I encountered such physics behavior before root motion was implemented, and the cause was not leaving the MovePosition() inside FixedUpdate(). Therefore I checked the code of Rootmotion only to find out that you already had it there in the right place. I also tried different settings with different rootmotion bone and different skeleton files (I tried the hip bone of Stretch man), and the jitter is constantly there.

My guess is that the animation itself is updated every frame, which caused the problem. But I couldnt find out a way to change the update mode to fixed update(), therefore I couldnt test my hypothesis.

Please check it out and I am looking forward to a solution. Thanks in Advance

Update Edit:
Yep, it is exactly that. I found the solution to add FixedUpdate into SkeletonAnimation script from this link:http://en.esotericsoftware.com/forum/Does-Spine-support-FixedUpdate-in-Unity-4336
It is actually quite simple, so I hope you can add it to the official build with an option to switch between update mode and fixed update mode. To be frank, this is ultra essential to integrate rootmotion with physics and it is actually kind of easy, with just a few lines of additional code.

In addition, I just come up with another idea: Can you add and expose another vector2 field to either RootMotion or DeltaCompensation? the purpose is to add other influence of velocity onto the rigidbody such as standing on a moving platform. The problem with MovePosition() method in Unity is that only the last time it is called in each frame counts, so we pretty much have to factor other velocity influences onto the RootMotion component. Thanks :grinteeth:

yinmo escreveu

Thanks a lot, Harald, that It works now as expected . Sorry that I didn`t check it out earlier since I thought it would not be under priority considering that it is not a system-breaking bug.

Thanks for getting back to us, glad it resolved your issue! Sorry to hear you're facing different troubles now.

yinmo escreveu

Yep, it is exactly that. I found the solution to add FixedUpdate into SkeletonAnimation script from this link: [..]. It is actually quite simple, so I hope you can add it to the official build with an option to switch between update mode and fixed update mode.

Actually the RootMotion component should already compensate for different frequency of Update() vs FixedUpdate() calls by cumulating and delaying the movement from Update() and applying it in FixedUpdate(). Normally any visual animation update should be performed in Update() since it is called once for each rendered frame. When animation is updated in FixedUpdate it would lead to potential visual jitter in animation when Update() framerate is higher than the FixedUpdate physics-framerate.

I would happily add an option to update skeleton components in FixedUpdate instead of Update, however we need to find out why calling it in Update() is causing problems that are not solved by the current (cumulative delayed) implementation. Could you perhaps send us a minimal Unity project that still shows your problem? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at what's the cause of the problem.

yinmo escreveu

In addition, I just come up with another idea: Can you add and expose another vector2 field to either RootMotion or DeltaCompensation? the purpose is to add other influence of velocity onto the rigidbody such as standing on a moving platform. The problem with MovePosition() method in Unity is that only the last time it is called in each frame counts, so we pretty much have to factor other velocity influences onto the RootMotion component. Thanks

Oh, thanks for reporting, that is unfortunate! I will add a property accordingly when working on your oscillation issue.

Harald escreveu

yinmo escreveu

Thanks a lot, Harald, that It works now as expected . Sorry that I didn`t check it out earlier since I thought it would not be under priority considering that it is not a system-breaking bug.

Thanks for getting back to us, glad it resolved your issue! Sorry to hear you're facing different troubles now.

yinmo escreveu

Yep, it is exactly that. I found the solution to add FixedUpdate into SkeletonAnimation script from this link: [..]. It is actually quite simple, so I hope you can add it to the official build with an option to switch between update mode and fixed update mode.

Actually the RootMotion component should already compensate for different frequency of Update() vs FixedUpdate() calls by cumulating and delaying the movement from Update() and applying it in FixedUpdate(). Normally any visual animation update should be performed in Update() since it is called once for each rendered frame. When animation is updated in FixedUpdate it would lead to potential visual jitter in animation when Update() framerate is higher than the FixedUpdate physics-framerate.

I would happily add an option to update skeleton components in FixedUpdate instead of Update, however we need to find out why calling it in Update() is causing problems that are not solved by the current (cumulative delayed) implementation. Could you perhaps send us a minimal Unity project that still shows your problem? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at what's the cause of the problem.

yinmo escreveu

In addition, I just come up with another idea: Can you add and expose another vector2 field to either RootMotion or DeltaCompensation? the purpose is to add other influence of velocity onto the rigidbody such as standing on a moving platform. The problem with MovePosition() method in Unity is that only the last time it is called in each frame counts, so we pretty much have to factor other velocity influences onto the RootMotion component. Thanks

Oh, thanks for reporting, that is unfortunate! I will add a property accordingly when working on your oscillation issue.

Package Sent.

Thanks for sending the reproduction package so quickly, we received everything and can reproduce the issue.
We will get back to you as soon as we've figured out the cause of the problem.

We have just implemented the improvents on the 4.1-beta branch, it turned out that providing animation updates in FixedUpdate was indeed the best way then combining root motion with collision. Unfortunately we can't add the changes to the 4.0 branch, as adding the FixedUpdate method to the skeleton components could break existing code where subclasses derived from said classes.

New 4.1-beta unitypackage is available for download here as usual:
Spine Unity Download

You could either integrate the changes of the commit to 4.0 yourself, or if you would like to update the SkeletonRootMotion components, you should be able to simply copy the 4.1 version of SkeletonRootMotionBase.cs over your existing 4.0 one (e.g. import just this single file from the 4.1-beta unitypackage).

Please let us know if this resolves the issues on your end as well. Thanks again for reporting!

Harald escreveu

Thanks for sending the reproduction package so quickly, we received everything and can reproduce the issue.
We will get back to you as soon as we've figured out the cause of the problem.

---

We have just implemented the improvents on the 4.1-beta branch, it turned out that providing animation updates in FixedUpdate was indeed the best way then combining root motion with collision. Unfortunately we can't add the changes to the 4.0 branch, as adding the FixedUpdate method to the skeleton components could break existing code where subclasses derived from said classes.

New 4.1-beta unitypackage is available for download here as usual:
Spine Unity Download

You could either integrate the changes of the commit to 4.0 yourself, or if you would like to update the SkeletonRootMotion components, you should be able to simply copy the 4.1 version of SkeletonRootMotionBase.cs over your existing 4.0 one (e.g. import just this single file from the 4.1-beta unitypackage).

Please let us know if this resolves the issues on your end as well. Thanks again for reporting!

Thanks for integrating it into the official build. And it does work as intended now.

But you forgot to add the extra vector2 field, which we talked about earlier, to account for external influence on rigidbody velocity.

yinmo escreveu

Thanks for integrating it into the official build. And it does work as intended now.

Thanks for the feedback, glad to hear!

yinmo escreveu

But you forgot to add the extra vector2 field, which we talked about earlier, to account for external influence on rigidbody velocity.

No, it's added as RootMotionBase.AdditionalRigidbody2DMovement.
SkeletonRootMotionBase.cs#L74-L82

Harald escreveu

yinmo escreveu

Thanks for integrating it into the official build. And it does work as intended now.

Thanks for the feedback, glad to hear!

yinmo escreveu

But you forgot to add the extra vector2 field, which we talked about earlier, to account for external influence on rigidbody velocity.

No, it's added as RootMotionBase.AdditionalRigidbody2DMovement.
SkeletonRootMotionBase.cs#L74-L82

Oh， sorry, I didn`t notice it. Thanks

No problem, it's better to ask than to wait indefinitely .

Harald escreveu

No problem, it's better to ask than to wait indefinitely .

Hi, Harald
Sorry that I have to bother you again :lol:
The jittery problem has only been improved to an extent. I found that if the velocity is high enough, the push and bounce problem will come back. You can simply verify that by increasing the time scale of the SkeletonAnimation.
I guess it is related to the script execution order, therefore I tried to modify them a bit, so far, there is no luck in that regard.
Can you look into this problem again? Thanks a lot.

yinmo escreveu

You can simply verify that by increasing the time scale of the SkeletonAnimation.

I'm sorry to say that I could not simply reproduce your issue in some local tests by setting skeletonAnimation.AnimationState.TimeScale to anything from 2 - 10. Could you please send us a minimal Unity project again that demonstrates this problem?

Harald escreveu

yinmo escreveu

You can simply verify that by increasing the time scale of the SkeletonAnimation.

I'm sorry to say that I could not simply reproduce your issue in some local tests by setting skeletonAnimation.AnimationState.TimeScale to anything from 2 - 10. Could you please send us a minimal Unity project again that demonstrates this problem?

Sure,

Thanks for sending the reproduction project, we could reproduce the problem. We will get back to you once I've figured out what's going wrong.

This issue has just been fixed on the 4.1-beta branch, see this issue ticket:
https://github.com/EsotericSoftware/spine-runtimes/issues/2046
Some optimization (avoidance of unnecessary calls when updating in FixedUpdate) will be added soon as well (hopefully tomorrow).

A new 4.1-beta unitypackage has been released:
Spine Unity Download
If you would like to only apply the changes (to a 4.0 installation), it's these two commits (as referenced in the ticket):
https://github.com/EsotericSoftware/spine-runtimes/commit/69b2a5ce13e4b213b9feda6deec290ccc35d0e0f
https://github.com/EsotericSoftware/spine-runtimes/commit/322d042309e99628e674dacf2ca61051f6235795 (this only adds the if-condition if (UsesRigidbody) around the block).

Please let us know whether this fixes the issue on your end as well.

Harald escreveu

Thanks for sending the reproduction project, we could reproduce the problem. We will get back to you once I've figured out what's going wrong.

---

This issue has just been fixed on the 4.1-beta branch, see this issue ticket:
https://github.com/EsotericSoftware/spine-runtimes/issues/2046
Some optimization (avoidance of unnecessary calls when updating in FixedUpdate) will be added soon as well (hopefully tomorrow).

A new 4.1-beta unitypackage has been released:
Spine Unity Download
If you would like to only apply the changes (to a 4.0 installation), it's these two commits (as referenced in the ticket):
https://github.com/EsotericSoftware/spine-runtimes/commit/69b2a5ce13e4b213b9feda6deec290ccc35d0e0f
https://github.com/EsotericSoftware/spine-runtimes/commit/322d042309e99628e674dacf2ca61051f6235795 (this only adds the if-condition if (UsesRigidbody) around the block).

Please let us know whether this fixes the issue on your end as well.

Thanks for such fast and great fix. It works like charm now

Very glad to hear, thanks again for reporting!

I will post again as soon as the aforementioned optimization update has been released as well.

The optimization changes (avoiding multiple unnecessary skeleton updates) have just been committed to the 4.1-beta branch: https://github.com/EsotericSoftware/spine-runtimes/commit/f7aaa25ee13777fca07747a6b5793c40ea92824d
A new 4.1-beta spine-unity unitypackage is available for download here as usual:
Spine Unity Download: spine unity 4.1 beta