Spinebot says "One potential solution is to periodically reset or reinitialize the physics system to prevent such issues. This could involve disabling and re-enabling the Spine object or using API calls to reset the skeleton or physics state." Are you able to verify that calling reset on the skeleton to its bind pose and or disabling/enabling the spine game object itself would indeed reset data related to physics? Much appreciated for your time and insights!

Hello Esoteric team!

We have some unusually long uptimes for our games (months). We're on a project using 4.2 physics for the first time, and we saw it happen twice where the physics stopped working. Animations driven by the animator remain working, just that the physics stopped. We're still trying to nail down if it is due to the long uptime or something else, in the meantime, we wanted to run this by you.

Would that kind of uptime raise some red flags with what you know about the physics system? If so, are there any things we could do to help prevent this? Maybe disabling the spine object every so often or some api call to reset the skeleton?

Thanks!

Thanks Misaki, I'll have a look at all that.

The documentation recommended SkeletonAnimation for using spine in Unity, so I'm wondering if our historical workflow is missing some modernizations. We often need our spine characters to maintain states; however, our artists tell us they would like to use features only found on the SkeletonAnimation spine object.

Is there something we're missing/overlooking that would allow us to have spine characters that maintain states while using the recommended SkeletonAnimation spine object? Would we need to roll our own state machine system tooling/editor window to work with SkeletonAnimation in that way?

Thanks!

Harald Gotcha, yea, the SkeletonDataAsset preview window. Thanks for the clarification, Harald!

I'll add one more nuance here about this that I should have mentioned earlier.

The other animations associated with this skeleton have a similar animated motion, key spacing, and timing and those do appear to play smoothly as expected in both Spine and Unity. The one difference is that the jerky animation described above did have some rather large weights on the in/outs of these keys that the others didn't. Between one pair of keys across 5 frames, the weights (key 1 out, key 2 in) created a very tight 'S' curve that lined up about in the middle of the two due to the weights being pulled super far away (likely on accident.)

Would the way spine's preview and unity's preview still be different in this way? This jerky motion is in the middle of the animation and not necessary blending in or out to another in the preview window (unless, I suppose, itself or a setup pose?)

Thanks!

Hey Spine team!

Myself and our artists have noticed that in the Unity inspector window of a spine asset when looping an animation, it seems to blend differently (in a bad way, jerky interpolation) then when looping the same animation in Spine's preview window (good way, smooth interpolation). I read the following over on https://esotericsoftware.com/spine-unity-main-components#Main-Components

We do use SkeletonMecanim with our spine objects in the scene, however I'm wondering if the preview window uses Mecanim under the hood to drive those animations and thus would fall under the warnings about SkeletonMecanim not guaranteed to match?

Thanks a heap for the insight!

Oh shesh, I re-read and see you fixed the binary export. So even if it has that floating vert is present the runtimes will still work if I'm understanding correctly.

Ahh, interesting, thanks Nate! Is the solution simply to have the artist find and delete that vert? Ideally we would like to use the binary export but if there isn't another option we could use the json export if it means the work is saved. Any question I could ask the artist that might help narrow down how it happened in their work flow?

Our artist is upgrading a 4.1 project to 4.2 and is encountering a message error upon loading the newly saved 4.2 project (after using project import > skeleton > older 4.1 project file) They had several incremental saves along the way. We found two versions where the suggested upgrade method works and then the next project where it breaks.

Could I email someone to find out if this is something we can fix on our end or if it's a new bug?

For what it's worth in the short term, I discovered you can manually type into the export .json file the following:
"output": ".\\export",
When you use the load settings option and select that setting export json file, it picks up the local path the project is in. In this case I had a folder locally called "export". In theory you could save the export settings file on your network and have everyone agree to use it and if they need to modify, make sure they hand-update that output field again.