anaskhan The problem is how to create animation that let you choose between 2 animations without affecting other.

I'm afraid I don't understand your question and your listed example. What do you mean by "create animation that let you choose between 2 animations"? And regarding "without affecting other", how is it affecting other animations?

In general you start animations via skeletonAnimation.AnimationState.SetAnimation() or enqueue it via AnimationState.AddAnimation(). Or when using SkeletonMecanim, normal Unity guidelines for the Mecanim Animator Controller apply, triggering the respective animation transitions via Animator parameter changes. Your game logic code should determine which animation is to be played at which time. E.g., a button press results in certain game logic events which then modify game state, and the game state modifications should then trigger the respective visual representation updates, including playing matching animations.

Sure, I'm happy to ramble a bit! Hopefully it's not too boring. Blog posts tend to take a lot of effort to polish up and we're pretty much always scrambling to get new versions released (recently more than ever). Even if we're seemingly silent, know we are working behind the scenes! We also try to stay active on the forums without fracturing our focus too much.

Sorry for the long silence between releases. We try to avoid that but sometimes a series of things (mis)align and it happens.

There will be a 4.2 beta. It's how we get it in front of you guys for feedback and to ensure that the non-beta version of 4.2 is stable enough for use in production. The beta will start as soon as it's ready. We're happy to get it out as early as possible but sometimes we can't do that, especially for bigger features.

The main challenge for a beta is that whatever we release should mostly continue to work correctly later. For example, we don't want you to do work in the beta and later be unable to open your project with a newer version because things have changed too much.

Depending on what we are working on, that may be very easy, for example if we're adding UI features or changing how tools work. If we're doing bigger changes that affect how things are stored in the project, then we need to be pretty sure about things before releasing them in a beta. If we release and then have to change them, it creates more work for us to massage the old beta project data into how the newer versions work, if that is possible. If not possible, we'd consider that a disaster.

What has happened for 4.2 is we had ideas for physics for a long time. We had prototypes even before 4.0. Finally we felt it was time, we did more serious prototypes and it looked promising. We did proper integration of physics into the editor. That was a significant effort for what's going on behind the scenes because it's very different than how Spine used to work.

Before 4.2, Spine is fully deterministic: for any time on the timeline, the pose of the animation is the same. With physics, that is out the window. The pose from physics depends on what was happening in the previous frames. This makes some things more complex in the Spine editor, but we got that done though, and it's nice. There are 2 modes:

1. Physics are computed all the time, even when playback is stopped. The pose from physics is affected by the animation playing, looping, bones that you move around, etc.
2. Physics are computed deterministically from frame 0. At any given time in the timeline, you always get the same pose, though that pose does depend on the previous frames.

An interesting aspect is that this is an important consideration at runtime. Your skeleton will animate with physics as you play animations, but you can also tell the physics that the skeleton moved in the game world space so that physics can respond.

For example, say you have a cape and a running-in-place animation. At runtime you move the skeleton around in the game world. You'll want to tell the physics about that movement so that the cape physics respond appropriately, not just to the animation movement.

You also need to be able to reset the physics at runtime. For example, when your character starts a new level, you don't want their cape physics flapping from whatever they were doing in the last level.

These things means there are some runtime API changes that you'll need to consider starting with 4.2.

Back to what's holding up the 4.2 beta -- so we've did the necessary changes for nondeterminism. Next we brought in how we want physics to work from our prototypes, created UI for configuring it, etc. It worked and was close to be released in the beta. The physics had a node and spring mechanism. You could do neat stuff, like take this setup:

And when animated you'd get a pretty realistic cloth simulation:

Sorry I can't find a GIF of that animating. I found some others though. To spice up this post a bit, here are a few more interesting GIFs. Two nodes and a spring:

More nodes:

More springs:

Collisions:

Nodes can be attached to bone to fix them in place or otherwise drive their position from bones:

You can of course go nuts, this is similar to the cloth setup in the editor screenshot above, but without gravity:

Nodes and springs can drive bones, affecting translation, rotation, and/or scale:

This next one is an animation being played repeatedly in the editor. It shows the two physics modes. When Simulate is not active, the pose resets when the animation repeats. When it is active, the pose is updated continuously even when the animation repeats.

Showing nodes and springs affecting bone rotation and scale:

Anyway, this was all pretty cool. However, we eventually decided it's not actually the way forward. It's useful for some things, but not everything we wanted. For other use cases it's hard to control. Despite being so close to release, we decided to redesign and see if we can do better. We came up with a new approach that better fits the use cases, did prototypes, ripped a lot of what we've done out of the editor. It's taking a long time and a little sad to nuke your own work, but the end result will be better. Ideally we would have made these changes earlier, when it would have been less painful. We tried, but we just couldn't have know without making it truly usable, and that took a lot of effort. Out of the pain will be born something even more beautiful.

So that's where we are now. We have the new things working in the editor again, but not fully and it's not ready to release. It's steadily getting closer though!

As for how we came up with Spine, I wrote a blog post a long time ago -- wow, it's been 10 years. That covers the early days and some of the technology used:
http://esotericsoftware.com/blog/building-spine

It's kind of funny that I was dorking around in QBasic as a teenager with stick figures. I had a really bad editor where you could move the stick figure points around. It stored the points as poses and the game played animations by interpolating between the point positions, very roughly how Spine works. I didn't revisit it until some 20 years later when I was working on games and found the need for Spine.