• Editor

  • Request: new Timeline Constraint, linking art and animations to bone positions

    anglais

Misaki To help with visualizing, here's some art I drew:

Imagine a character turnaround that uses all of these hand frames at different angles. Rather than manually swapping out each art frame as the character's arm turns around, I would like the ability to create a (manually spaced) sequence of these images and then link it to a bone's rotation, so I could get easy ease-in/out on my images, etc. This would be useful for multidirectional rigs, like this one by armanimations. As you can see in that video, currently Spine struggles with complex rigs like this, as the animation process of swapping frames at the end was very manual and tedious.

Nate The 1d/2d sliders are also a very cool idea, and could be an alternative to using timelines. But I feel like so many animation tools are already coded to work with timelines that it might be easier to repurpose them? By linking a timeline to a bone property you'd basically be creating curves by value instead of by time, so it's more for automating basic tasks than direct use. In the use case described above, I would not be altering this bone-linked timeline after the image sequence was properly laid out to match the bone angles, and I would actually want it to be decoupled from the other animations I was working on. It's sort of a baseline "what draw order and hand frame are typical when the player is facing this direction?", that only gets manually re-keyed when necessary.

Using sliders would also solve the problem though, so I'm looking forward to what you folks come up with as a solution. I just definitely want a way to link bone properties to ranges in the sliders, as it solves a lot of the image art <-> skeleton linkage issues I'm having right now.

      Related Discussions
      ...

      Thanks for your additional thoughts!

      There are some advantages to using animations rather than sliders. From a high level, I think sliders are simpler for many tasks, while animations can be more powerful.

      Note an animation that shows a sequence of images would be a single attachment with Sequence checked, then that sequence keyed on frame 0 to play at a given FPS.

      I think when interpolating with a slider, the curve wouldn't be embedded in the slider, instead you would move the slider position using a curve.

      There's a lot to think about! We'll revisit this in the future for sure, hopefully soon. We want 4.3 to be a quality of life release, where we do a lot of long requested smaller features, then maybe 4.4 can be slider fun.

      17 jours plus tard

      Sounds great! Just to be clear on my last point about sliders, I guess I'm talking about an additional "slider constraint", that automatically moves the slider position based on a chosen bone property and range. While manually keying the slider position is fine, I really want something linked to existing properties that doesn't have to be keyed at all. For things like physics, it makes sense that you don't want to have to meticulously match a curve to what it's doing automatically.

      For more, unnecessarily detailed info: 😅
      The end goal for my turnaround example above would be similar to how isometric setups work currently, with an x-scaled bone parenting a rotatable bone to get oval-shaped rotation. You can then make a bunch of these oval-like joints centered on a rotation axis, to position every joint by its distance and angle from that central axis, defining your character in a 2.5d/polar coordinate way. By then linking the rotation offset of the child bones to a master "rotation" control bone that offsets them all, you can animate something like a walk cycle once and get a full 360 degrees of walking animations for free. In code you can just change the rotation of one bone via transform constraints to turn your character to the correct direction, and all the ovals swivel to that offset. But most importantly, if you want arm rotation to be decoupled from the body for better animations, you can just nest 2 control bones via transform constraints to get a "master" controller and an "arm" controller.

      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. Currently I can make a separate turnaround animation that has the correct draw order and art frames at every angle for every piece that rotates independently, then blend them in code by freezing animation layers and manually setting them to the correct turnaround point, so it somewhat works in runtime code. In Spine though, this is impossible, so I'd have to check all my animation angles post-export to do any kind of cleanup.

      I feel like there are a lot of use cases where these kinds of art control bones would be helpful to the animation process. So yeah, not really a core feature, but very powerful in certain circumstances, like with physics and "3d" rigs. I feel like this is a situation where a picture is worth a thousand words though, so I'm going to stop rambling, haha.

        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!

          2 mois plus tard

          So I just learned about Moho, and it turns out they have a perfect example of what I was suggesting here! Their feature is called Smart Bones.

          This may only let you map a bone's rotation to poses, but the additive blending (since each timeline only affects some values) and ability to make bones move with physics (for automatic follow through at the end of a head turn, etc) is what really makes this concept powerful for Spine too, imo.

          It might be worth checking out their software to see how they handle this, if you're interested in a live demo of the feature. Gives you all of the research with none of the dev time.

          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.

          4 mois plus tard

          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.

          7 mois plus tard

          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 a répondu à ça.

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

                    • Nate a répondu à ça.

                        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 spine的新功能总是如此好用！希望能快点见到并使用它们~

                                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!