RemDust

Thank you very much for the new commit, can't wait to check it out !

About delta compensation. I gave some thoughts about this exemple :


The green is the movement as designed in Spine Editor. It's a fairly commun parabolic jump from enemy towards the payer.
In blue we can see the needed delta compensation, which is, in this case only on the X axis.

If I'm correct using Y delta compensation would override the Y part of the jump, correct ?

So in this case I guess we could simply don't use Y compensation but then even if the graphics display correctly my rigidbody2D would actually still be on the ground and "slide" towards the player. In this easy case of same ground/level it wouldn't be too problematic but i can see this being an issue going forward.

I have a lot on my plate right now, I hope I'll be able to elaborate and think more tomorrow !
As always, thank you for your help Harald :)
RemDust
  • Postovi: 224

Harald

I will come up with a solution that covers the above jump use case. I will post here on the thread once this update is complete.
Avatar
Harald

Harri
  • Postovi: 4325

RemDust

Can't ask for a better support, you rock :rock:
RemDust
  • Postovi: 224

Harald

Thanks for your kind words 8).

A commit has just been pushed to the 3.8 branch.
changelog.md je napisao/la:Root motion delta compensation now allows to also add translation root motion to e.g. adjust a horizontal jump upwards or downwards over time. This is necessary because a Y root motion of zero cannot be scaled to become non-zero.
The delta compensation example script should automatically have this Allow Y Translation parameter enabled, which should now adjust root motion automatically.

Along the way I also fixed scale of Transform, Skeleton, and parent bone not being respected by the delta compensation computations: delta compensation should now work consistently with arbitrary scaling.

A new spine-unity 3.8 package is available for download here as usual:
Spine Unity Download
Please let us know if this now works as desired for your use case. :nerd:
Avatar
Harald

Harri
  • Postovi: 4325

RemDust

Harald je napisao/la:
Along the way I also fixed scale of Transform, Skeleton, and parent bone not being respected by the delta compensation computations: delta compensation should now work consistently with arbitrary scaling.

Please let us know if this now works as desired for your use case. :nerd:
Hi Harald,
thank you so much for putting the effort in making Root Motion better :)

Based on my quick new tests Delta compensation seems really good even with marginal cases now, thanks ! :nerd:

Now, about Ridigbody2D root motion I still have a problem. Not talking about delta compensation here.
I encounter conflicts between physics and root motion movement :upsidedown:

Let me explain a bit.

The root bone of the enemy is at (0,0) in editor, so basically right at the ground level.
Now back in Unit, I parent my skeleton to my actual GameObject Enemy containing physics and box2d. I have to size and match my box collider to fit the enemy, and make the unity gameobject root fit to the skeleton root. To make the issue obvious if I set box 2d/rigidbody too low (in y value) compares to the skeleton, root motion will constantly push my body 2d up in the air, even targeting a "neutral value" of (0,0) like an Idle animation. Opposite case, if my body 2D is too high above the root bone, root motion will tend to push the rigibody into the ground.

conclusion -> If my gameobject box 2d doesn't pixel perfect-match the ground level of the spine root I have a these cases where root motion conflicts with physics as physics and root doesn't "target the same ground level".

Does that make any sense to you ? How would you setup your gameobject and skeleton to avoid that ? I can try and make a quick drawing if that helps to explain the issue ^^

I suppose that I miss something obvious and that there is a usual way to make this all fit nicely :think:


[EDIT]
I tweaked the colliders a bit and even if I'm almost 100% sur that it fits, using Root Motion with Rigidbody2D gives me shorter jump attack that root motion only without physics. Changing the mass, linear or angular drag doesn't seem to affect the distance in any way.
Is this the expected behaviour ?
RemDust
  • Postovi: 224

Harald

RemDust je napisao/la:thank you so much for putting the effort in making Root Motion better :)

Based on my quick new tests Delta compensation seems really good even with marginal cases now, thanks !
Thanks for your kind words, glad it works better now! 8)
RemDust je napisao/la:Now, about Ridigbody2D root motion I still have a problem. Not talking about delta compensation here.
I encounter conflicts between physics and root motion movement :upsidedown:
Unfortunately I could not reproduce your problem, or I simply misunderstood your setup. If I make the BoxCollider2D larger so that it intersects with a ground collider (reaches into the ground too deep) and play a horizontal jump animation, I see normal physics compensation behaviour moving the object smoothly upward out of the ground. Did you receive other behaviour? Could you then please prodive the mentioned drawing to explain things a bit more?

Apart from that, I noticed that the root motion script does not interact well enough with Rigidbody2D yet, as I noticed some jittering occur when playing a jump animation. Since it does not occur (or is not visible enough) on a walk animation, it remained unnoticed until now. I have created an issue ticket here:
https://github.com/EsotericSoftware/spine-runtimes/issues/1880
Avatar
Harald

Harri
  • Postovi: 4325

RemDust

Harald je napisao/la:Unfortunately I could not reproduce your problem, or I simply misunderstood your setup. If I make the BoxCollider2D larger so that it intersects with a ground collider (reaches into the ground too deep) and play a horizontal jump animation, I see normal physics compensation behaviour moving the object smoothly upward out of the ground. Did you receive other behaviour? Could you then please prodive the mentioned drawing to explain things a bit more?
Well I kinda fixed it, it came from a bad setup where the skeleton root bone is not perfectly aligned with the physics object root :
an animation of the root bone, even at (0,0) results in a constant "force" applied on the rigidbody.
I suppose because the rigidbody tries to reach the position of the skeleton root bone which (being a a child of the rigidbody,) is also moving, like a dog chaising it's tail ^^) :upsidedown:

A perfect alignement of root bone and physics object root get rid off this effect.
Harald je napisao/la:Apart from that, I noticed that the root motion script does not interact well enough with Rigidbody2D yet, as I noticed some jittering occur when playing a jump animation. Since it does not occur (or is not visible enough) on a walk animation, it remained unnoticed until now. I have created an issue ticket here:
https://github.com/EsotericSoftware/spine-runtimes/issues/1880
Then it may be related to the real problem I'm facing : root motion with rigidbody gives me significantly different results than root motion without physics. Please see image below for better explanation ^^

RemDust
  • Postovi: 224

Harald

RemDust je napisao/la:I suppose because the rigidbody tries to reach the position of the skeleton root bone which (being a a child of the rigidbody,) is also moving, like a dog chaising it's tail ^^)
I tried radically different BoxCollider2D offset to the root bone, but didn't see any vertical "position fighting". Nevertheless, I could reproduce enough jitter in a jump animation which is dealt with in the aforementioned issue ticket, it might perhaps fix the other issue as well.
RemDust je napisao/la:Then it may be related to the real problem I'm facing : root motion with rigidbody gives me significantly different results than root motion without physics. Please see image below for better explanation ^^
Thanks for posting the image, this is indeed problematic. I wonder if this is due to similar problems as in the ticket above, or if it's maybe due to any physics effects being applied (although I don't think that the Linear Drag or other friction effects should lead to this result). Anyway, we will see one the above problem is solved, let's hope it's all due to the same problem.
Avatar
Harald

Harri
  • Postovi: 4325

RemDust

Let's hope it all comes from the same issue :whew:
Would you ping me when you'll have it updated ?

As always thank you for your hard work :)
RemDust
  • Postovi: 224

Harald

I will post here on the forum once a new unitypackage has been published. You can also subscribe to the issue ticket, then you will receive additional notifications upon any progress (and any associated commit).
Avatar
Harald

Harri
  • Postovi: 4325

RemDust

Harald je napisao/la:I will post here on the forum once a new unitypackage has been published. You can also subscribe to the issue ticket, then you will receive additional notifications upon any progress (and any associated commit).
Awesome, thank you 🙏🙏
RemDust
  • Postovi: 224

Harald

A bugfix for moving the Rigidbody and Rigidbody2D components has just been released, it should now work very smoothly without any jitter at all. It has been a bit tricky, but should now also respect scale at every level of the skeleton.

New 3.8 and 4.0-beta spine-unity unitypackages have been released and are available here as usual:
Spine Unity Download

Unfortunately after testing high gravity scale on a Rigidbody2D, I could reproduce your reported "distance is not the same as without a rigidbody" issue reported above. This is not present at all when setting Gravity Scale to zero, and the effect gets larger the more I increase this value, so it seems to be the cause of this problem. The RootMotion components use Rigidbody2D.MovePosition() which unfortunately states:
Rigidbody2D.MovePosition.html je napisao/la:"Note: MovePosition is intended for use with kinematic rigidbodies. "
https://docs.unity3d.com/ScriptReference/Rigidbody2D.MovePosition.html
So this seems to be a mainly Unity related problem, unfortunately I don't yet know what to use instead of Rigidbody2D.MovePosition() when using non-kinematic dynamic rigidbodies. Admittedly I would have expected no friction or similar effect to take place when using MovePosition() with the resulting absolute position value.

If anyone knows any workarounds or insights regarding this subject, please let me know, any input is greatly appreciated!
Avatar
Harald

Harri
  • Postovi: 4325

RemDust

Hey Harald !
Sorry for the very late reply. A lot of work lately.

Thanks for the fix of the jitterring :clap:

So I tried to reduce the gravity scale and this is indeed the source of the distance problem.
Good thing is we know what is it, bad thing is we don't know how to tackle this right now.

I need to be able to increase the gravity scale for huge ennemies. I'm gonna post on Unity forum for an alternative for MovePosition but I'm afraid that moving the position of a non kinematic rigidbody in Unity is intended by adding forces...

I guess the REAL solution would be to get rid off Unity physics and hardcode my own "physics" and collisions but it seems like a pain at this stage ^^'

[EDIT & WORKAROUND]
So !
I've been investing a bit and I was almost sure it had something to do with friction.
I was making the assumption that no physics material in Rigidbody would set friction to zero (specially with linear and angular drag set to zero in rigidbody properties).
Actually creating a 2D material with zero friction for the rigidbody with a root motion solves the "distance problem".
I can see cases where a no friction material can be an issue : an enemy standing on a non horizontal ground would be sliding...

So here is what I can think of :
Set material to rigidbody, friction to whatever, let's say 1.
When using root motion, simply set friction to zero, and revert it back when the movement is done.
What do you think ?
Does it make sense to have it as a default behaviour in the RootMotion script Harald ?
RemDust
  • Postovi: 224

Harald

Thanks for the detailled writeup!
RemDust je napisao/la:When using root motion, simply set friction to zero, and revert it back when the movement is done.
What do you think ?
Does it make sense to have it as a default behaviour in the RootMotion script Harald ?
Unfortunately I'm afraid this is not an option for being overridden by the RootMotion component all the time, as there are situations as you've mentioned in which you would want to have friction set to a non-zero value. Unfortunately movement is also never done, so it's hard to decide when to set friction back to the normal value. So I'm afraid this solution would cause another group of problems. :wounded:
Avatar
Harald

Harri
  • Postovi: 4325

RemDust

As far as I'm concerned, I'm using a setup where I use custom AnimationReferenceAssets, they have a isRootMotion property and my animation script checks for this flag on animation start and animation complete events to enable/disable root motion.

I guess I'm gonna use the same events to set/reset the friction.

I understand that this behaviour might be very specific to my setup but I'll let you know how it's working going forward :)
RemDust
  • Postovi: 224

Harald

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.
Avatar
Harald

Harri
  • Postovi: 4325

yinmo

Harald je napisao/la: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
yinmo
  • Postovi: 20

Harald

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.
Avatar
Harald

Harri
  • Postovi: 4325

yinmo

Harald je napisao/la: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 :D . 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
  • Postovi: 20

Harald

yinmo je napisao/la:Thanks a lot, Harald, that It works now as expected :D . 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 je napisao/la: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 je napisao/la: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.
Avatar
Harald

Harri
  • Postovi: 4325

yinmo

Harald je napisao/la:
yinmo je napisao/la:Thanks a lot, Harald, that It works now as expected :D . 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 je napisao/la: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 je napisao/la: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.
yinmo
  • Postovi: 20

Harald

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!
Avatar
Harald

Harri
  • Postovi: 4325

yinmo

Harald je napisao/la: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!
:D 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
  • Postovi: 20

Harald

yinmo je napisao/la:Thanks for integrating it into the official build. And it does work as intended now.
Thanks for the feedback, glad to hear! :)
yinmo je napisao/la: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
Avatar
Harald

Harri
  • Postovi: 4325

yinmo

Harald je napisao/la:
yinmo je napisao/la:Thanks for integrating it into the official build. And it does work as intended now.
Thanks for the feedback, glad to hear! :)
yinmo je napisao/la: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
yinmo
  • Postovi: 20


Natrag na Unity