search

EsotericSoftware / spine-editor

Issue tracking for the Spine editor.
http://esotericsoftware.com/
29 stars 2 forks source link

Use a separate skeleton for Preview to match additive runtime behavior #547

Open HaraldCsaszar opened 4 years ago

HaraldCsaszar commented 4 years ago

Currently the Preview window in Spine seems to display an additive animation track differently than SkeletonViewer (built from latest 3.8 git status) and the spine-unity runtime.

Steps to reproduce: Perform the following steps in Spine and SkeletonViewer:

  1. Open the latest version of the Raptor project.
  2. [Spine only] Switch to Animation mode in Spine, open Preview window
  3. On track 0, select walk animation.
  4. On track 1, select gun-grab animation, enable additive mix mode.
  5. Observe the mixed result: In Spine, the animation will look "normal", in SkeletonViewer, the arm will spin around quickly.

In Spine, it behaves as if the walk track is applied on top of the setup pose, the non-keyed arm rotation leads to a stable base-rotation to add to. So the gun-grab animation looks quite "normal" and usable. In SkeletonViewer (and also in spine-unity), the additive gun-grab track is added in an ever-increasing cumulative way to the current rotation, the setup pose seems not to be used as base-rotation, instead the last frame's rotation seems to be used.

This has recently been reported on the forum: http://esotericsoftware.com/forum/Unity-mixing-animation-bug-13634

(Are there additional calls performed in the Spine preview window that are missing in SkeletonViewer?)

HaraldCsaszar commented 4 years ago

The reproduction asset Cat.zip attached in the forum thread also shows the same ever-growing rotation value behaviour, although all bones are keyed in all animations.

HaraldCsaszar commented 4 years ago

Related problem: When enabling Animation clean up upon Export to e.g. .json, keys where there is no difference to the setup pose will not be exported. This will then trigger the same problem in runtimes, not applying the setup pose on the base track and also not applying the non-exported key, thus adding to an ever-increasing rotation value.

NathanSweet commented 4 years ago

Re: Clean up, clean up should not be used in that case. We have #461 to improve that.

NathanSweet commented 4 years ago

In the raptor project, the gun-grab animation keys rotation for front-arm, while the walk animation does not. If you apply an animation with additive and no other animation is setting the keyed value, the keyed value will be incremented every frame, which is probably not what you want.

This doesn't happen in the editor because the Preview view is using a skeleton that is also used for other things, so each frame the editor calls Skeleton setToSetupPose. The editor doesn't expect that a pose from a previous frame affects the next frame. This is a bit unfortunate because it makes it difficult to detect problems when using additive, and doesn't allow preview if someone were to rely on that behavior (eg to purposefully have something spin forever).

We should let Preview have its own skeleton so the behavior can better match when happens at runtime when using additive.