shy

This rig setup mostly works in Spine right now, the only problem is that the art/attachment layers don't understand the concept of a control bone or the transform constraint, so draw order is static and also art frames have to be manually swapped out.

You are right! This is indeed an issue for which Spine should provide a useful solution.

Thanks to the addition of folders for draw order in 4.2, it is now easier than older versions to create animations that require changing the draw order of many slots, such as rotational animations. (For example, in the older version, if you wanted the right arm to appear before the body, you would have to move all the slots for the rightarm, right hand, right hand ring, bracelet on the right wrist, etc., but by moving the "right arm" folder, you can manage them.) However, it would be nice to be able to save frequently used poses as a kind of preset and use them as needed during animation, not managed by keys as it is now. With the current management method, too many timelines are listed on the Dopesheet view, and because timelines cannot be locked, keys may be deleted or be moved at any time while working. For example, when offsetting, it often happens that the keys for changing the direction of the character placed at frame 0 are moved and the loop is broken. I know this is just my fault and can be avoided if I'm careful, but I can't help but wish I could control the poses more strictly.

I think the best approach to improving such cases may still be debatable, but I can at least very much agree with what you feel is the problem itself. Thanks a lot for your detailed feedback!

Interesting, thanks! We'll still want to fully explore the solution for Spine, but it doesn't hurt to see how others have done similar solutions.

I,m also looking for a solution like this discussion...

To be able to switch or control slots or images based on a bone angle will improve a lot my animation process.

I am also interested in this. I think both a slider solution and bone solution could work. You could use a transform constraint mapping from the bone to the slider. There are advantages to having the bone transform control things. And it doesn't have to only be the rotational transform. It could be any of the transforms.

You could hardcode the keys on export so that these "smart bones" are an editor tool (probably easier and better for performance) or allow them to be controlled in the runtime dynamically. I can wait for 4.4 but I wanted to show my support for this.

Yep, lately we've been actively working on Spine's first iteration of sliders for 4.3! And you're exactly right, sliders controlled by bones enable all kinds of things.

In the video, they key the rotation twice, and that somehow defines the range. By that I mean any given arm rotation has to map to a frame in the "action" timeline. What if rotation is keyed more times? The action timeline could have the same rotation in multiple places. Does it ignore the key placement and just use the minimum and maximum rotation keys as the range?

Here's a slider for an animation that from 0-50% turns all attachments red and turns off IK, then from 50-100% turns all attachments transparent:

Anything you can key, you can put on a slider. Then once you can control a slider from a bone, any bone movement can do anything.

Nate What if rotation is keyed more times? The action timeline could have the same rotation in multiple places. Does it ignore the key placement and just use the minimum and maximum rotation keys as the range?

I wouldn't think you could key rotation multiple times. It would have to use the min and max for ranges. I guess if there was a way to do it, you would have to merge the keys somehow where the rotation is keyed more than once?

Nate Anything you can key, you can put on a slider. Then once you can control a slider from a bone, any bone movement can do anything.

I love it! This is going to be a powerful feature and will speed up the animation process significantly.

Nate 这太棒了，想要这个功能很久了，有点类似于live2d的参数条。还有另一个强大的功能【变形器】也可以考虑一下，功能是可以给一个或者多个网格，再嵌套做变形。

strawbry_jam I wouldn't think you could key rotation multiple times.

Yeah, same. It's a weird use of keying the rotation to define the range, presumably so they don't have to provide another way of doing it. At least it seems to be pretty fast to setup. A lot of apps seem to shoehorn similar features and have weird ways to set things up, eg the way ToonBoom does it also uses the timeline with some weird conventions.

yugutou Grid deformers are a nice feature and we've considered it. We do vertex transforms on the CPU because it is generally fast enough, provides more flexibility, and ports well to many game toolkits. The main drawback to deformers is the runtime cost. We may still do it in the future.

Nate This is amazing to see and is precisely what I've dreamed about having! Super exciting! Is there any chance that this even in the super early phases will be included in the 4.3(.15)-beta?

Either way, keep up the great work! This update is proving to be absolutely incredible!

Additionally, I'm well aware that the runtime itself is open source but it'd be amazing if there were a way for me to contribute to the development of the editor as well! I'd love to help you guys out in any way and improve this fantastic platform. Has that ever been considered?

Not suggesting that it should be under a full 'Open Source' i.e. OSI license, but with clearly defined protections and boundaries similar to those defined in the runtime such that others could aid in the development process without compromising the business model. I'm sure I'm not alone in that I'd absolutely love the opportunity be more hands-on and actually contribute directly with e.g. fixing up bugs or even starting on initial implementations of workflows such as this or other ideas without taking capacity away from the team. This could additionally bridge a gap allowing projects to extend the runtime with project-specific needs ahead of e.g. a plugin ecosystem or something.

Just thought I'd share some thoughts

You will be able to play with it soon, in 4.3.15-beta which we'll release hopefully in a few days. As always, spine-libgdx will be updated first, but it will take longer than usual (probably weeks) for other runtimes to be updated, as there are a lot of changes that need to be ported.

The editor is the cornerstone of our business, so I'm afraid we can't share the source code. Plus it's already hard working on such a large app with others. The runtimes' source is available, any effort to improve those would help free us up for other things!