Misaki Hi Misaki, thank you so much for your prompt reply! It’s really helpful to know what can be done in Spine runtimes! My spine file already got a lot going on, so I don’t want to further complicate it.
In this case, using seperate skeletons would be the easier solution for my current project.
Now I’m wondering for reusing/importing animations to different skeletons, is it better to animate bones rather than animate IKs? My understanding is that if I animate the bones, the animations would look the same for characters that are physically different. I could just change the length of each bones. Is it right?
Animations not working using skin based transform constrains
Erika Hi Erika, wow! Thank you so much for your super detailed demonstration! You are so skilful and I appreciate your time and effort for doing this!
After discussing with our IT technician about our project setups and my current skill level, we might need to use different skeletons and import animations to them like you suggested.
We want to reuse the animations as much as possible without having to tweak them for every different character though. In this case, is it better to animate bones rather than IKs? My understanding is that if I animate the bones, the animations would look the same for characters that are physically different. I could just change the length of each bones to match new characters’ body parts. While if my animations are solely based on keying in IK’s positions, I will then need to re-adjust each animation’s IK’s positions for different characters. Right?
Emi
Each approach has its ups and downs, so if you choose to separate the skeletons, you will have to reimport the same animations across all skeletons and apply the tweaks. This can be an advantage if you plan to have not many animations but lots of customization in your files. Vice-versa, if you won't have too many characters, but lots of animation, the effort in using a single skeleton is worth it.
Considering what you're doing is pixel art, that usually has fixed angles in its pure form (0, 90, 180, 270 of rotation, translating items only at full pixels or half) there can definitely be advantages in importing animations expecting less tweaks.
If you're using a hybrid approach (the base art is pixel art, but you don't care about keeping pixels at an angle, or will later apply a pixel art filter) then it means that you will be able to animate freely, but given the odd angles you may get, the matching may not be as precise and therefore reliable.
Emi My understanding is that if I animate the bones, the animations would look the same for characters that are physically different. I could just change the length of each bones to match new characters’ body parts.
While it's true that if you reimport an animation, it will add the same amount of translation/rotation/etc. to a child bone, but keep in mind this is relative to its setup pose.
Ultimately, the length of a bone does not matter for animating purposes, only for IK and path constraints as it's used by these to calculate the bones' postions.
So you could also not change the length of a bone, it's more important to change its position technically and broadly speeking.
Emi While if my animations are solely based on keying in IK’s positions, I will then need to re-adjust each animation’s IK’s positions for different characters.
It depends, sometimes all that's needed is to reposition an IK target in setup and that's it. Sometimes the target needs more tweaks.
I think the amount of work for IKs would likely be similar both in a single skeleton or multiple skeletons situation.
As for bones themselves, you'll need to tweak their animations in both cases as well, the real question is:
is it going to be more time consuming to add new skins or to add new animations in the long run? and that should tell you which approach to pick.
If you have to constantly add new animations, don't separate the skeletons, if instead you have to add tons of little hats, different body shapes etc. do separate them if you like your sanity.
Emi Erika answered your question about whether you should animate bones or IKs, so let me skip it. I'm glad to hear that the information about what can be done with the Spine runtime was helpful!
If it is the case that you do not need to use mesh deformation and just want to attach an image to a bone, e.g. a sword or a gun or something rigid, it may be worth considering making the image follow the bone at runtime. If you use the spine-unity or spine-godot runtime, it is also possible to refer to the draw order of a specific slot. This means you can insert an image to the draw order of a skeleton at runtime. However, there are differences in what each runtime can and cannot do, so it may not be possible depending on which runtime your project actually uses.
If you have any more questions, feel free to ask in this forum.
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!
6 أيام لاحقا
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!
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!
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 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.
13 أيام لاحقا
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. 