1) Ah, the docs should say mixDuration (the total duration of the mix), not mixTime (the value increasing over time from 0 to mixDuration). Sorry for the confusion! I've updated the documentation pages.

2) The thread you linked is pretty involved. You summarized the thread, sort of, but it's hard to tell if your summary is correct. Can you please explain what you are trying to do?

Asking multiple things in one thread is fine!

3) Thanks, we'll take a look.

4) We can do a new release tag. The 4.0 branch should be quite stable (4.1 beta is almost complete).

I can speak to 3 and 4:

3. I've created an issue for the spine-cocos2d-objc bug you found regarding clipping: https://github.com/EsotericSoftware/spine-runtimes/issues/2073

The integration example in the spine-c documentation is already quite involved, so we opted to not add descriptions for clipping there. You do however not have to dig into any third party code, or even spine-cocos2d-objc. The canonical runtime for C is spine-sfml, you can find its renderer there: https://github.com/EsotericSoftware/spine-runtimes/blob/4.0/spine-sfml/c/src/spine/spine-sfml.cpp#L293

I've updated the spine-c documentation with a link to that implementation.

4. Sorry this happened. When we do a Spine Editor release, we also tag the current release Spine Runtime branch. Generally, the release branch always compiles. In this case, we didn't catch the compilation error and the branch was still tagged.

For what it's worth, there is no need to use a specific x.y.zz tag of the Spine Runtimes repository. If you are using Spine Editor x.y.zz, you can use the latest commit from the corresponding Spine Runtimes repository branch x.y. E.g. You are using Spine Editor 4.0.31, so you can use the latest commit to the Spine Runtimes repository branch 4.0. The release tags on the Spine Runtimes repository are for us to be able to go back and see what the Spine Editor version was using as the runtimes. They aren't really that meaningful for users of the runtimes. Always use the latest commit from the x.y branch is the rule of thumb.

We've added a 4.0.64 tag to match the latest 4.0 editor:
https://github.com/EsotericSoftware/spine-runtimes/releases/tag/4.0.64

I would Assume that while I'm adding animation, it will be applyed on top of current transformations if those elements not changed in "idle".

We started out this way, but it caused a lot problems. In most cases it's a lot easier for the animations combined to define the skeleton's pose, without remnants from previously applied animations.

I understand your run/idle situation now, thanks. Often at runtime you need to know where the skeleton is for things like hit detection, so it's often impractical to have the animation moving the skeleton around the screen. If your animations position your game objects, your game code is unlikely to know where the objects. Also it can make it difficult to serialize your game world's state, if you need that. There are a few ways to go about it:

The easiest thing to do is play your idle animation on the right side of the screen. This may be sufficient for simple scenarios, where you need only a few animations like idleLeft, run, idleRight.

The next easiest thing is to know where your skeleton has been moved to after you play an animation. For example, you play idle, then run, when run is complete you know you need to move the skeleton across the screen, then when you play idle it's on the right side. If you want to smoothly transition from run to idle it may take some planning. It's easiest for the run animation to end in the idle pose, so the transition from run to idle is in the animation.

That approach is useful for complex movements, like climbing a ladder, when the exact position of the skeleton isn't important during the animation (maybe they can't be hit while on the ladder).

Another option for you can be to use additive animation. This is where you set TrackEntry mixBlend to MixBlend add. This causes an animation to be added to the pose from lower tracks. For example, it can be used to do facial expressions during other animations. For example, to use it for that you first need to key the face on a lower track. If you don't then every frame the additive animation will be applied on top of the pose from the previous frame, quickly getting out of hand. Next, you play your animations, run, jump, idle, etc normally. Then on a higher track you can play one or more face animations that are applied using MixBlend add. This changes the face no matter what else the character is doing. You can use the TrackEntry alpha to partially apply an animation, for example to blend between facial emotions using a weighted system.

Or, you could move your skeleton in your code, at a speed that matches the animation. See the run or walk animations in the spineboy example project. To do this you need to animate without moving the skeleton across the screen. It can be helpful to move the skeleton while animation, then remove those keys when finished. Ghosting offset can be used to determine the speed the skeleton needs to move at runtime to match the animation.

That approach can work for linear or simple movement. It's also necessary when the player has a lot of control of the skeleton's movement, like a platformer game. In that situation you may want to adjust the animation speed based on the skeleton's movement speed, so they match. For example, when moving in a platform, often movement starts slow and then gets faster.

For more complex movement, like a shambling zombie, it would be difficult to write code that moves the skeleton in a way that matches the animation. For this it's better for the animation to define the movement, where the animator has full control. At runtime you can use a technique called "root motion". This is where you take the motion that would be applied to the root bone and you instead apply it to the entire skeleton. This allows an animation to move your skeleton in your game world in complex ways. With root motion, after you play your run animation the skeleton would be moved across the screen, then when you play idle, it would play on the right side of the screen.

Implementing root motion is relatively advanced. We provide code to do it in Unity. The docs are here, the code is here and here. It is split because Unity has two types of scene graph nodes that are position differently. Also it is relatively complex because it has some advanced features you may not need, like rotation.

"Hold previous" is probably not what you want. It applies the previous animation fully in a mix from one animation to the next, ie A -> B. If you have multiple animations, eg A -> B -> C then yes, it will apply A and B and then C and with hold previous it won't mix out the previous animation. However, AnimationState tracks intend mixing to be used from one animation to the next. To apply multiple animations, it's intended to use different AnimationState tracks.

If you really want to change how animations are applied, you can modify the runtimes, as mentioned in the thread you linked. A drawback to that is you'll find you often need to key things in an animation to reset things that were keyed in an animation played previously. This leads to keying almost everything at the start of most animations. That is tedious, bloats the animation data, and it makes applying an animation at runtime slightly more expensive to have many extra timelines. As you add things to your skeleton, you'll need to revisit existing animations and key things to reset them. It's also error prone, as you won't notice any problems until you happen to play an animation that keys something that some other animation forgot to key to override. Lastly, setting the skeleton back to the setup pose will snap, rather than transition smoothly.

Sorry for the long post!

can we connect 2 skeletons with IK?

You can, at runtime, by having code move an IK target bone to the world position of a bone in a different skeleton.

kolya-j a écrit

here I might confuse lower tracks, aka track 0, 1, 2 and lower track animations, aka animation in the same track but played before.

Yep. Tracks are animations applied on top of each other. We call transitioning from one animation to another on a single track "mixing".

Hold previous applies to mixing to another animation on the same track. The snapping from hold previous happens in this case: one animation raises an arm and a running animation is set for the same track using hold previous. Running doesn't key the arm. When the arm raise animation is no longer applied (the mix duration is reached), the arm will snap back to the setup pose. AnimationState doesn't keep the pose from an animation that will no longer be applied, it resets the keyed properties for that animation back to the setup pose. You would need to modify AnimationState if you want to avoid this resetting to the setup pose.

Hold previous is working for you because you keep applying your run and idle animations. You are mixing from run -> idle I guess with a very high mix duration and hold previous, so you get both run and idle on the same track. That is how AnimationState works, it is not accidental behavior, but it isn't how we usually see AnimationState used. What happens if you need to play more animations? Say you need to run up the screen and then idle again.

kolya-j a écrit

I assume that bone index won't be changed during lifetime.

Correct.

kolya-j a écrit

So I did try to implement extra animation on other track, which will move skeleton to needed position to keep it there for idle. And looks like it works.

I should have suggested something like this. It makes sense to use an animation to position things, then play your idle and other animations on other tracks so they happen wherever the "position" animation has placed the bones.

spTranslateTimeline_setFrame(pTranslateTimeline, 0, 0, position.x, position.y)
spTranslateTimeline_setFrame(pTranslateTimeline, 1, duration, position.x, position.y)

Note if you have two keys with the same position, you could just add the key at frame 0. Maybe your two keys have different positions in your real code though.

The way you did it programmatically by creating an animation to move the bone to the end position will work, depending how you use it. Do you play run and then when it is done, play run position on a different track to keep the position from run, even if run is no longer applied?

Let's step back and think about how it could be done in the editor, eg by animating run, then cutting all the translate keys for the root bone of your character and pasting them into a new animation. Then you have two kinds of animations:

1) Animations that change the position, like run. For those, you could play run on track 0 and run position on track 1. This gives you the run animation and the position animation.

2) Animations that don't change position, like idle. For those, you just play them on track 0. The run-position animation continues to play on track 1, keeping the character where the run animation wanted it, even though you aren't playing run anymore.

If you later play another animation that affects movement, like walk up, then you play walk up on track 0 and walk up position on track 1.

You would probably find it annoying to separate the translate keys from the rest of the animation in the editor, so you could do it at runtime by removing the translate, translate X, and translate Y timelines from the run animation and creating a new run position animation with those timelines.

I checked unity code, which you linked. And as I understood you looking for shift between time A and B. This kinda clear. But I didn't understand what you do with this shift after that?

It removes the movement from the root bone and applies it to the GameObject, which is Unity's scene graph node. This makes the movement of the GameObject come from the animation. Unity can do hit detection, physics, etc that is based on the position of the GameObject. Also other code can move the GameObject around to run, jump, get hit, etc.

kolya-j a écrit

I don't see option in spine to play multliple animations from multiple tracks.

This can be done in Preview:
Preview view - Spine User Guide

kolya-j a écrit

in this preview each track can play only 1 animation at a time. So No way to test how it will looks like to play "run + idle" on track 0 and "run position" on track 1.

Preview does (almost) everything AnimationState does (it uses AnimationState). Play run on track 0, set the mix duration, change the track 0 animation to idle, click track 1, set the run position animation. If needed you can temporarily set the speed to 0, so your run and run position animations start at the same time. We have plans to improve the preview.

kolya-j a écrit

just take all transtate from one bone and split it

Yep, I think this is the way to go! I wanted to explain doing it in the editor mostly as a way of understanding what is going on, then find a way to cut out the work by doing it programmatically.