I'm not entirely sure if I understand but, you could have 1 animation for the wings plus all the other animations of the body you mentioned and simply run both at the same time using different animation states.

I believe they are trying to add "mixing" animations (animation blends) in the editor, so in theory you can animate the wings on one animation, the rest of the body in other animation and mix both of them.

Definitely something we want to add at some point. We already have a task on our trello board for this https://trello.com/c/v9xhnfx2/69-blend- ... the-editor

The task is for previewing in the editor multiple animations applied at the same time. At runtime you still need to apply them at the same time. If you want a single animation, you can copy keys from one animation to another.

It would be great to have an "animation mixer" which is essentially like the dopesheet but instead of showing keys it shows entire animations. This enables composite animations, which is useful for the scenarios you listed as well as cut scenes.

An animation mixer is a lot of work though. For now you can get the same effect by applying multiple animations at runtime. Eg, make two animations, "flap" and "land", then apply them both each frame at runtime. This avoids duplicating the animation data.

This does require more management at runtime, but in many cases you need to do it this way anyway. Eg, you are flying around flapping, then you land while still flapping. You want the flapping to continue while you land, but if the flapping was baked into the landing (whether by copying keys or using a composite animation) then the flapping would reset to the start as soon as you started landing. It wouldn't have a smooth transition from flapping in the air to landing and flapping.

Nate, Shiu,

I've recorded a short video to show you how we work at the moment with nested animations and how do we put them together and test them.

As it's not yet possible to do the nesting, we have developed our own stuff (or let's call it a software) for testing the animations. It's nothing fancy, but it works well for us now.

We have many characters in our game. We call them "champions".
Each consists of different skeletons which are in runtime put together.

So basically how it works,
I export a champion,
import textures & JSONs into our "Superbombastic Champion Tester Software" and where it is put together and I test it.

Here's the video, you can see there the workflow:
http://youtu.be/jvLZ-Y6oLg0

Maybe this will help you to picture our workflow and see how we do it...
Maybe you'll come up with some new ideas what can be done

btw any ideas / feedback well appreciated :notme:

Aye, others are doing the same as you, eg for Delver's Drop.

I just had an epiphany. To do cutscenes and control skeleton draw order during animations, you would use a skeleton that only has slots containing other skeletons. This "scene" skeleton would control the draw order. Super cool! 8) Taking this further, if the scene skeleton had keys to change animations for the attached skeletons, we'd basically have an animation mixer!

Did this just now:

Image removed due to the lack of support for HTTPS. | Show Anyway

This works already, the attached skeleton uses the slot's draw order, can be put in a skin attachment, etc. For drawing, the attached skeleton x/y is set to the slot's bone, so if you want to offset to you need to move the root bone of the attached skeleton. Next the attached skeleton's root bone rotation and scale is adjusted by the slot's bone world scale and rotation. Support for rendering this would need to be implemented for each runtime, but it isn't too hard (just rendering another skeleton when processing each slot's attachment to render).

I moved it to the arm for an example:

Image removed due to the lack of support for HTTPS. | Show Anyway

Unfortunately there is a bit of cleaning up to do (eg, the goblin should have been animated walking as it was in the editor, but Spine didn't realize it was being exported) and I won't be able to get to it until Sunday (have a family thing Saturday). I should be working on meshes and not this, but if I can finish it soon I'd like to release it. Keep in mind that official runtime support for this would be limited to spine-libgdx. Meshes really need to get done!

We need to do some thinking about how this integrates with all aspects of using Spine, so we keep the workflow sane. Eg, now you'll likely have animations in multiple skeletons that you intend to use together. How to best organize this? Maybe the scene or "master" skeleton has an animation with keys that set the animation of the attached skeletons. This way you can pick a single animation, and when you play it all your skeletons will play the right animation. Of course, other times you'll want to control them separately at runtime (eg, a gun firing).

There is also some complexity around how the attachment loader will find the skeleton to attach at runtime.

Woooooot that's supercool looking forward to this

Bit of a bump, but this is exactly what I'm looking for now.

I want to be building animations with fully swappable components. Switch out the head, the tail, etc, where the geometry of each can actually be different. Skinning works for artwork changes, but not for skeletal changes. Plus it's all or nothing with skins. The above feature would technically allow me to have body skins, head skins, etc.

Oh boy, I can see this leading to a very big Spine file.

Hi there !

Any update about that ???
That feature would be mindblowing for projects that need high visual modularity.

Also, would you have in mind a feature like External file referencing ? Like in Maya, for example. That would help large projects.

Thanks,
ben

Runtime support for this would only be for libgdx initially, other official runtimes would get support for it later on.

I noticed the trello board said this is now done for the libgdx runtime.

How should this be implemented, should this pseudo be sufficient?

SkeletonAttachmen attach = new SkeletonAttachment("mynewattachment");
attach.setSkeleton(myAttachmentSkeletonReference);
someSlot.setAttachment(attach);

This alone seems to disregard the slot's position in the world, and the attached skeleton just seems to play about relative to the origin (0,0)

Yea it's there for libgdx, though I'm not sure how stable it is. The code you show should position the skeleton at the bone for the slot it is attached to. See SkeletonRenderer.

Currently the SkeletonAttachment seems to place the attachment at the worlds origin. Tomski may have tracked the issue to the skeletonRenderer class. Im looking through it but things seem look fine code wise to my amature eyes. I noticed that the bone.getWorldX and Y methods don't seem to return the correct values in the 2nd draw method, but i have no idea why that would be the case. Any chance you guys will be able to revisit the SkeletonAttachment system for libgdx sometime soon?