Spine Root Motion Script with Unity 2018.2.11f1

thislop

Hi there,

We recently set about updating the current project to Unity 2018 after completing a development milestone.

Ran into some interesting behaviour regarding the SkeletonUtilityBones [follow] and how they now interact with Pharan's experimental spine root motion script we've been using up to this point.

https://imgur.com/a/48iWi94

Any help with this would be greatly appreciated.

Pharan

The experimental root motion script wasn't written in the context of SkeletonUtility.

We'll check it out though.

Can you briefly describe what you're trying to achieve with it and the current trouble it's causing? (just in case there's anything additional we need to watch out for)

Are you saying it worked fine before you updated Unity? It might just be a matter of indeterminate script execution order if that's the case. I don't think there's anything fundamental about SkeletonUtility or the root motion script that implements things differently based on Unity version.

thislop

Thanks guys!

We were using the script to drive player movement through a root-motion bone we had created in spine. This was to avoid foot sliding and retain the sense of scale for the Mech.

Here's the walk cycle working in the Unity 2017 runtime as intended.We were using the skeleton utility hierarchy to nest particle effects, do certain camera tracking actions etc. and generate Spine Hitboxes.

What's further interesting, is that this problem doesn't happen with BoneFollower in Unity 2018.

If it wasn't for the Spine Hitboxes being necessary for Combat, we'd be able to move most of it over to using BoneFollowers.

The displacement seen in the gif occurring for Hitboxes as well is the only critical bug from this for us.

Pharan

We haven't started work on this yet.

But for what it's worth, BoundingBoxFollowers are independent of the SkeletonUtility system. They will work with SkeletonUtility or BoneFollower or with any other component you come up with.

So if it's just two or three bones, using BoneFollower would be fine. SkeletonUtility is still the way to go if you inevitably have to follow several bones related to each other in the hierarchy.

It's definitely an execution order problem, though it doesn't matter what Unity version it is. I was able to replicate this problem in Unity 5.6

The current workaround for ensuring the correct update order seems to be just to disable and enable SkeletonUtility one frame after SpineRootMotion has the chance to initialize.

Currently, our components don't have the APIs to ensure event order so changes to make this cleaner would need to be done in the next version of Spine-Unity. We can do this in 3.7.

thislop

Thanks for getting back so quick! -the current workaround is more than enough for us to fix the problem in the meantime 🙂