- Edited
Animations synchro in the previews and in the engine
Hi!
The title speaks for itself. As you can see in this GIF, I have two animations in layers. The character running and the glasses that follow the movements and its deformation. Except, I can't get the animation of the glasses to start at the same time as the running animation. Is it possible in the preview? I also ask myself the question once in the engine.
Or do you know a method 100 times more efficient to be able to add objects in layers that would follow all the deformations of all the animations? haha.
Hello, the most efficient way to add objects in layers is to use skins. You have only one animation, and not an animation per object, and every cosmetic is animated within it, but only the ones you want can be active. More on the topic: Skins - Spine User Guide and Skins view - Spine User Guide
As Erikari described may be easier for you. If you do want to play to animations at the same time in Preview currently the way to do that is to set the speed to 0, set animations on multiple tracks, and then increase the speed. This is a little clunky, we have plans to improve it!
Thanks for the quick answer!
The problem is, I already use the skins in the project to change characters and there will already be LOT of them in this project. So I was looking for a way to avoid making a new skin by objects for each character skin... Which would be really long and inefficient.
That's why I did this method. An animation for the run for the objects on the head, another for the objects in the hand, I duplicate the animation and just change the active object in each anim and dones.
More efficient this way no ?
And can we set the synchro on the Engine easily?
Thanks!
In code it's very easy to play two animations at the same time, eg:
state.setAnimation(0, "run", true); // 0 is the track, true means loop
state.setAnimation(1, "sunglasses", true); // 1 is the track, true means loop
It's efficient in that you don't have timelines for bones that may not have attachments (eg running with no sunglasses, the sunglasses bones would still be animating with Erikari's setup). This is unlikely to matter though, since presumably performance when all the bones do have attachments will be acceptable.
It is likely to be harder for you, eg you need to animate the sunglasses without seeing the run animation, or only seeing it in the Preview view. You'll end up with many animations instead of many skins, so I think there's no avoiding a long list. With skins you can apply multiple at once and see everything directly in the editor viewport.
Ok great for the engine! Thanks!
Hmmm, It depends on the project that sure, but for us, I still think this gonna be quicker this way. I explain myself.
For the moment we think we're going to have about 100 characters and 50 objects. And probably 5 anims in total (2 "Run" with mesh deformations, 2 "Idle" without mesh deformation, and one High Five anim, with potentially mesh animation). So potentially 3 anims with mesh deformations and 2 without.
(The 2 "Idle" animations without deformation just require the appearance of the object attached to the bone of the face for example, in the case of the glasses, so only one "activation animation" is necessary for these two)
Case 1, we make a new skin per character and per object =
100 (Characters) * 50 (Object) = 5000 Skins....
Case 2, we make 4 anims per object (3 anims with deformation + 1 for both Idle, without deformation)
50 * 4 = 200 Anims.
It's very different, isn't it? Or is there something I didn't understand?
Thanks!
I believe the reason you aren't seeing Skins as a viable solution is that you may be unaware that multiple Skins can be made activate at once at runtime (and in the editor!). The gif on the page Erika linked to demonstrates this: Skins view - Spine User Guide
But maybe it would be more helpful if you could actually see the project file, so you can experience what it's like to toggle the individual skins: https://esotericsoftware.com/files/projects/twitch/twitch-dudes.zip
Basically, since your situation only involves base character swaps and cosmetic equips, you would have a separate skin for each character and a separate skin for each object with NO character involved.
In your 5,000 skins scenario, you seem to be envisioning making a different skin permutation for every possible character + object combination, but since you can activate multiple skins at runtime, the separate equip skins effectively serve exactly the same purpose as your separate animation tracks, in that they make the appropriate equip visible. Therefore for 100 characters + 50 objects, you only have 150 skins total.
If you had a project where the characters had hundreds of possible combinations of equips and customizations, using Skins this way would enable you to set things up such that only the currently equipped items are included in the atlas (if you had things set up to build the atlas at runtime), which is an important optimization step if, for instance, the number of possible equips would otherwise spill into many many pages worth of atlases and increase the draw calls by an unacceptable amount. Anyway, your current scenario seems simple enough that I doubt that will be an issue, but I just wanted to toss my two cents in to help you understand the power and flexibility that being able to combine Skins allows!
Wow, ok. Thanks! 
So, I'll check that and come back later if needed!
Thanks!
Thanks for making things clear, Emjay! :happy:
A “little” tricky question about skins.
If I want to have the possibility to have each Skin of objects/characters with the linked mesh so that a modification can be done in one go on all the skins while being able to modify a "child skin" without impacting the others if necessary, the simplest way is to have a "default" Skin with all the others Skins and that has to be the “parent”, right?
Example, if I need to have many different characters while having many different "hats", different "glasses", different "scarves", etc, the best thing is to have a "default" skin with the basic templates, animations and mesh modifications of the characters and objects, then make sure that all the other skins inherit the modifications and are linked to this "default" skin, right?
Because there, on the file I'm working on, I did it a little “randomly” (wrong, that's for sure), without paying attention to it and now I have problems such as, for example, if I delete some "parts" of some Skins, these parts are also deleted on others while I wish they would stay there, others have double parts, that kind of thing... Which is not very practical. But I know it's due to an organizational problem on my side, but so I wonder how to reorganize it in an effective way.
(If it helps you understand what I'm talking about, it's on the file I sent you for this bug [runtimes] JSON reading - null deref bug in MeshAttachment · #1284.) For example, if you look at the bone "Caps/Hairs_Patch" I have my two skins locations "Cap_Patch" and "Hairs_Patch" that I wanted to be linked to each other, because the images will not have the same names according to the characters but they will potentially have the same mesh modifications. I only managed to display one on the "CH_FoG" skin, but on the others, I have both of them and if I delete one, it deletes itself on all the other Skins... I think I really did something stupid here haha, I'm going to have to work on that again, but so I come to ask these questions to be clear, because now I'm confused and going in circles. (By the way, I wonder if this problem I made isn't the reason for the bug above... Skins that depend on several other skins or that kind of thing?)
Sorry in advance for the question difficult to understand and thanks!
Thanks for the additional insights on your project, it's very much appreciated since it helps us while analysing the bug referenced above!
You're welcome! ^^.
Another bug appeared when people do stupid things! Haha.
But is that what I have to do for the skins?
Thanks!
@FogRyu I'm having a hard time following your question, but I'll try and shed a little more light on skins and linked meshes.
If you deform a linked mesh, the deform will be carried over to all of the skins where Inherit Deform is enabled for the same linked mesh. If you need to tweak the deformation for a particular skin on one of the linked meshes, you will need to disable Inherit Deform or click Unlink. Clicking Unlink will give you the option of copying existing keys from the original linked mesh.
Deleting an attachment under a skin placeholder will not delete the attachment from all of the skins, only from the currently active skin. Deleting a skin placeholder will delete the skin placeholder from all skins.
I hope this helps.
Thanks for your answer!
Yeah, it's not simple but I think I start to get it.
Shiu wroteDeleting an attachment under a skin placeholder will not delete the attachment from all of the skins, only from the currently active skin. Deleting a skin placeholder will delete the skin placeholder from all skins.
And deleting an attachment under a skin placeholder wich is the "parent" of a linked mesh, removes this "attachment" in all skins that got his "child" "linked version".
That's why I make a skin with ALL the "skin placeholders" and all animated. Then I duplicate it and from it I make the others, removing unnecessary "attachments".
Seems a good way to do it?
Thanks!
And deleting an attachment under a skin placeholder wich is the "parent" of a linked mesh, removes this "attachment" in all skins that got his "child" "linked version".
Yes, deleting the "parent" or a linked mesh removes the attachment in what you call "child" skins.
That's why I make a skin with ALL the "skin placeholders" and all animated. Then I duplicate it and from it I make the others, removing unnecessary "attachments".
Seems a good way to do it?
Yes, this is how I would do it as well
Great, thanks a lot!!! That really helped!