[runtimes] time scale 0 mixing bug

[badlogic]

See http://esotericsoftware.com/forum/TS-TimeScale-0-during-mixing-bug-10953

Port
abdbb10
84ae36f
f95465f

• spine-libgdx

---

• spine-csharp
• spine-xna
• spine-monogame
• spine-unity
• spine-tk2d

---

• spine-c
• spine-cpp
• spine-sfml
• spine-cocos2d-objc
• spine-cocos2dx
• spine-ue4

---

• spine-ts core
• spine-ts webgl
• spine-ts canvas
• spine-ts threejs

---

• spine-as3
• spine-starling

---

• spine-lua
• spine-love
• spine-corona

[NathanSweet]

We added a special case (859dd76 and issue #806) which causes a "mixing from" entry to immediately finish if the "to" entry has timescale=0. This was done to fix this user's problem. That is a bad use of timeScale though, and the special case finishes the mix without it having a chance to reset to the setup pose, causing this issue.

If we remove the special case, mixing to an entry with timescale=0 will never finish the mix. This is valid, but can lead to an extremely long linked list, like in the issue above. To stop that, we could consider a mix complete, even if mix time hasn't reached the mix duration, when timeScale=0 AND the "to" entry is not the current entry. The only tricky part is getting the entry to be applied one last time, so it returns the properties it was modifying to the setup pose.

[NathanSweet]

Reopening with a new potential fix: f95465f
We should do a group review before porting this, to be sure. The commit causes mix time to no longer be affected by TrackEntry timeScale. This is more sane than using either the from or to time scale, which change the mix durations in often surprising ways.

[NathanSweet]

Review passed, porting can commence. Checkboxes above have been reset.

[smaren]

I'm the one who posted the bug. I have implemented your solution and I find it a bit confusing.

My use case is that I want to forward one track while pausing the other tracks. I do this by setting the timeScale of all track entries on other tracks to 0. But with the current solution, when I call animationState.update() on, the track entries that are being mixed, are all ticked along with the track that is being forwarded despite both the mixingFrom and mixingTo entry having a timeScale of 0.

Could a reasonable solution not be to also mix the time scale such that in the beginning of the mix it uses the timeScale of the mixingFrom entry and ends up using the timeScale of the mixingTo entry?

Anyway, just wanted to share my thoughts, I have a workaround where I set the mixTime back to its original value after the call to animationState.update()

[NathanSweet]

Hmm, thanks for explaining your use case more. Yours may be the only use case where scaling the the mix time using track entry timeScale is desired. In other use cases, doing that results in surprising/wrong behavior. Eg, if the from timeScale is zero and that is used for the mix time, mixing from that to something else may never complete. Same if the to timeScale is zero and used for the mix time.

It's an interesting idea to use some mix of the from and to timeScale. However, I'm not sure how this would work -- the mix time is usually what decides how the from and to entries are mixed. Any ideas? We could use (from.timeScale + to.timeScale) / 2), though if that was (0 + 1) / 2, I'm not sure you'd want the resulting 0.5 time scale. Eg, if you are mixing from a "frozen" entry (0) to a non-frozen entry (1), do you want the mix duration to take twice as long (0.5 time scale)? In that case you might want to use 1 (or the to timeScale), but in other cases you might want the from timeScale.

It may be that we just don't have enough controls (despite having a ton!). We could have a mixTimeScale. This would be the time scale to use for the mix time when mixing from the previous animation to this animation. This may be only marginally better than your workaround. You can sort of freeze the mix now by setting the mix duration to the highest float value.

@pharan @badlogic Any thoughts?

[badlogic]

I think an explicit mixTimeScale is the best solution, provided the default behaviour reproduces what's currently the default.

…

On Thu, Jan 3, 2019, 12:41 Nathan Sweet ***@***.*** wrote: Hmm, thanks for explaining your use case more. Yours may be the only use case where scaling the the mix time using track entry timeScale is desired. In other use cases, doing that results in surprising/wrong behavior. Eg, if the from timeScale is zero and that is used for the mix time, mixing from that to something else may never complete. Same if the to timeScale is zero and used for the mix time. It's an interesting idea to use some mix of the from and to timeScale. However, I'm not sure how this would work -- the mix time is usually what decides how the from and to entries are mixed. Any ideas? We could use (from.timeScale + to.timeScale) / 2), though if that was (0 + 1) / 2, I'm not sure you'd want the resulting 0.5 time scale. Eg, if you are mixing from a "frozen" entry (0) to a non-frozen entry (1), do you want the mix duration to take twice as long (0.5 time scale)? In that case you might want to use 1 (or the to timeScale), but in other cases you might want the from timeScale. It may be that we just don't have enough controls (despite having a ton!). We could have a mixTimeScale. This would be the time scale to use for the mix time when mixing from the previous animation to this animation. This may be only marginally better than your workaround. You can sort of freeze the mix now by setting the mix duration to the highest float value. @pharan <https://github.com/pharan> @badlogic <https://github.com/badlogic> Any thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1194 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfYBGzW6C0e9mWCb4sDRZFktFllJA9Hks5u_ex_gaJpZM4XZeT1> .

[smaren]

I am not sure why it is a problem that a track entry with timeScale 0 never finishes mixing? If the tracks have not started mixing then they never will since the track entry never proceeds with a timeScale of 0.
It is a potential problem if the mixingTo entry has a timeScale of 0. Then the mixTime will crawl to a halt as it nears its end. However, that may be a decent outcome?

Another issue with the current solution is that it will proceed with the main delta value. So if both the mixingFrom and mixingTo entry has a timeScale of 2, they will proceed as if the timeScale was 1 - in this case the timeScale should arguably be 2? If the the timeScale is also mixed the behavior in this case would make sense. I think it is important for the solution to have a sane flow in the more common cases. Simply disregarding the timeScale during mixing seems unintuitive