Spine 4.2 Physics and TimeScale (and some other queries)

Cranktrain

Absolutely loving the new Spine 4.2 physics feature, in both the editor and in the Unity runtime.

Works great, looks great, super easy - probably my favourite new Spine feature since... discovering Spine itself. Top marks!

One thing I'm confused about is how a SkeletonAnimation's TimeScale should relate to the physics simulation. To make up an example, let's say I have a character with a running animation, in Unity I set the TimeScale to 0.1 for a light jog, but set it to 2.0 for a full-on sprint.

If I'm just using the physics simulation for the character's clothes and hair, at 0.1 speed the physics will seem to act in slow-motion, and at 2.0 timescale the physics will act unrealisitically fast. Running slowly or quickly, the strength of gravity ought not appear to change, you know? What seems intuitive to me is that the physics simulation will tick along at 1.0 regardless of the timescale, but clearly I'm out of step with the default setting here.

(In some other cases, I'll animate something in Spine and when I bring it into the game, I just adjust the timescale till the speed looks right, rather than going to all the hassle of moving all the key frames around on the timeline back in Spine itself, as the way to slow it down or speed it up.)

Am I misunderstanding what adjusting the Timescale is designed to do, and there's another way I should be playing an animation at different speeds, without physics changing?
Is there a need for another setting/toggle that will apply physics at an independant rate separate from TimeScale? An additional PhysicsTimeScale, for instance?

While I'm asking questions about physics - is there a way to, at runtime, toggle physics constraints off altogether to save performance? Does setting: constraint.Mix = 0 skip the whole physics calculation?

Thanks!

Nate

I'm glad you are liking Spine's physics!

AnimationState is separate from physics. Changing AnimationState timeScale will cause animations to go faster or slower.

Physics are applied using the skeleton time. This way time can pass differently for the skeleton/physics than it does for the animations.

That said, the important detail is how the skeleton time is adjusted for a particular game toolkit. My guess is you are using SkeletonAnimation timeScale:
EsotericSoftware/spine-runtimesblob/4.2/spine-unity/Assets/Spine/Runtime/spine-unity/Components/SkeletonAnimation.cs#L245
You probably want to set AnimationState timeScale so the skeleton time isn't scaled.

Cranktrain Does setting: constraint.Mix = 0 skip the whole physics calculation?

It does:
EsotericSoftware/spine-runtimesblob/4.2/spine-csharp/src/PhysicsConstraint.cs#L137
Don't be shy about jumping in the code, hopefully you find it very straightforward! (at least outside of the black magic parts 😉).

Cranktrain

Ah hah, I didn't know about the distinction between skeleton time and SkeletonAnimation timeScale, I was indeed just setting it in the editor. I will apply it to AnimationState instead.

Thanks for all the answers!

Harald

To make up an example, let's say I have a character with a running animation, in Unity I set the TimeScale to 0.1 for a light jog, but set it to 2.0 for a full-on sprint.
Cranktrain I will apply it to AnimationState instead.

Note that it's likely not a good idea to change the TimeScale for the whole AnimationState just to play a single run animation faster and slower, as then e.g your attack and shoot animations also run equally faster. You might instead want to change TrackEntry.TimeScale of your run animation only.