• Editor
  • Animations not working using skin based transform constrains

Erika Thank you for the very clear explanation, Erika! I understood now.
We already have hundreds of existing characters from our old game to be imported into this new project, but we don't have that many animations in comparison. So, separate skeletons would work better for us.

All our characters share the same starting pose (standing straight idle pose), so bone animations should work.

Thanks again, Erika. I appreciate your help!

Misaki okay! We use spine-unity. Thank you so much for the tips! I will keep them in mind. ^^

6 gün sonra

Misaki Hi Mistaki, you mentioned that "if the Spine runtime your project is using is spine-unity, it is also possible to separate the animations as AnimationReferenceAssets and use the AnimationReferenceAssets for other skeletons."
I made 2 different skeletons (A and B). The setups are the same for both skeletons because I copied and pasted the spine file. Our Unity developer did testing on them, but it seems that AnimationReferenceAssets is not working for us:
Skeleton A was exported with 5 animations. Skeleton B was exported with only 1 of the 5 animations.
In Unity, only the 1 animation exported with skeleton B can make B move. The other 4 animations from A cannot make B move.
I found a relevant forum post here: https://zh.esotericsoftware.com/forum/d/10201-psa-spine-animations-as-unity-asset-references/8
Harald pointed out "check that the AnimationReferenceAsset is of the same SkeletonDataAsset that the SkeletonAnimation is referencing". However, in my case, the skeleton data won't be the same, as you can see below.



Please let me know if I misunderstood anything and how to make this work. Thank you!

    Emi Hmmm, as far as I have tested on my end now, it can be successfully applied to AnimationReferenceAssets created from different SkeletonDataAssets, as long as the setup is exactly the same. But it is possible that I am not understanding it correctly, I will ask Harald to check this thread.

    • Emi bunu yanıtladı.

      Misaki Hmmm, our setup should be exactly the same since it's a direct copy and paste. May I please double check one thing: with your 2 skeletons (A and B), if you have 5 animations in A and 0 animation in B, all 5 animations from A can be applied to B and make B move?
      It only works for us if A and B have the same amount of animations.

      Thank you!

        Emi

        May I please double check one thing: with your 2 skeletons (A and B), if you have 5 animations in A and 0 animation in B, all 5 animations from A can be applied to B and make B move?

        Yes, like in the following video, it works on my end:

        Spineboy-A has multiple animations and Spineboy-B has no animations at all. When Spineboy-B references the AnimationReferenceAssets generated by Spineboy-A and plays the animations, it works as expected.

        Anyway, I have asked Harald to check this thread, please wait for his answer for more details.

        • Emi bunu yanıtladı.

          Misaki Thank you so much for the video! Our unity technician tested again and it's all working now. We couldn't figure out what went wrong before but we are glad it's working now. ^^

          • Düzenlendi

          @Emi Unfortunately I have to state that re-using an AnimationReferenceAsset for a different SkeletonDataAsset (SkeletonData actually) is not generally supported, although it will work under certain constraints.

          When playing an animation via a different SkeletonDataAsset's AnimationReferenceAsset, it's doing nothing more than applying the Spine.Animation of one SkeletonData to a different SkeletonData's skeleton. So it's applying SkeletonA.AnimationWalkA to SkeletonB, which might have no animations at all.

          As Spine.Animations are applying Timelines to a Skeleton, which are mostly modifying bones, slots, etc at certain indices, this will go well as long as both Skeletons have the exact same setup (name and order) of bones, slots, etc. Unfortunately Animations that use DeformTimelines (deform keys, also called free-form deformation) will not apply the deformation animation to a different skeleton, because they don't use indices alone but also a direct object reference to a SkeletonData's VertexAttachment. This VertexAttachment object reference does not match the different Skeleton's VertexAttachment, and thus the deformation animation will be skipped, ignoring a part of your animation.

          Also, it's just working due to the current way animation timelines are implemented, so it works by chance. More things might fail in future verisons of Spine like 4.2 or later versions, should the implementation change.

          So in short, it is not recommended to apply animations to a Skeleton from a different SkeletonDataAsset. Sorry to say that!

          Likely the best reliable solution would be to automate your workflow via scripting and copy the animations over at the Spine project level, and make sure they are exported correctly for each skeleton project. If the number of animations is a problem on the Unity side, you might want to automate your Unity project setup as well using editor scripting, e.g. automatically creating and assigning each AnimationReferenceAsset at each imported skeleton according to a template. This way you could save manual repetitive work and still ensure everything is playing back as it should.

          • Emi bunu yanıtladı.
            13 gün sonra

            Harald
            Thank you for your detailed response and sorry for my late reply. Our unity developer was away and just got back to work.
            In regards to your last paragraph about the best reliable solution, may I please clarify that you meant we need to import all the animations to each skeleton that we use? Then export each skeleton to our unity developer. If so, why do we still need to use AnimationReferenceAsset in unity since all the skeletons will have all the animations? Can't we just play them from skeleton? Or there are some benefits we can take from AnimationReferenceAsset? Please correct me if I misunderstood anything.

            Is it correct that the most reliable way for doing my project is for me to import all animations into the 3 skeletons/spine files and export for development team, then they need to update 3 skeleton files to ensure animations are in. Will this work for later spine version as well?

              Emi may I please clarify that you meant we need to import all the animations to each skeleton that we use? Then export each skeleton to our unity developer.

              Yes, I meant to ensure that each skeleton export contains all animations.

              Emi If so, why do we still need to use AnimationReferenceAsset in unity since all the skeletons will have all the animations?

              AnimationReferenceAsset serves to allow selecting an animation by assigning a Unity asset to Inspector properties, instead of writing code to query an animation by name and cache the resulting Spine.Animation object for multiple use. The AnimationReferenceAsset does nothing more really, it does not serve as stand-alone animation data or the like.

              Can't we just play them from skeleton?

              You always play an animation of a skeleton.

              Is it correct that the most reliable way for doing my project is for me to import all animations into the 3 skeletons/spine files and export for development team, then they need to update 3 skeleton files to ensure animations are in.

              Yes. If you have an enormous amount of animations, your developers could automate the Unity setup process via Unity editor scripts.

              Will this work for later spine version as well?

              I'm not sure I understand this question correctly. In general, Spine and the spine-unity runtime will always allow you to play the animations of an exported skeleton which have been exported along with it, yes. 🙂

              • Emi bunu yanıtladı.

                Harald Thank you so much for your reply! You've been a big help! We understand what to do now.

                @Emi glad to hear it's been helpful, thanks for getting back to us!