• Runtimes
  • [spine-ts] automatically play sequence attachments

In our skin system, we are adding some skins with sequence attachments. For example, we have many static weapon attachments/skins, however, now we are adding new animated (sequence) skins like flaming swords, pulsing glowing wands, shields with animated coats of arms, etc.

For our animated items, we want them always to be animated and looping. However, we cannot just add them to the skin and have them loop, my understanding is that we also need to add an animate key in the Spine animation for each separate attachment for each animation. We plan on 100s of different animated items, and having to key each one for each animation is complex; we need a separate animation for each to be applied to a higher track, and we need to change some of the animation directions based on the action (switch to a different view).

What would work well for our case is if there was a way to default enable animations for skins with sequence attachments without having to add an animation key. For example, set up a default FPS, looping style for all sequence animations applied once added to a skin.

I have done PRs for spine-ts in the past, so I will also look at doing this myself unless there is already a method to do this already available (that I have not seen yet.) Any help/direction regarding what code to change/add for the PR would be greatly appreciated.

This feature will be used in the C3 spine plug-in in our game.

Related Discussions
...
  • Изменено

I suggest configuring your skin at runtime, then loop through each slot and checking it's attachment. If the attachment is a region or mesh, check if it has a sequence. If so, create an animation that plays the sequence as you like. Code to create an animation looks like:
Slot color change animation from code [libgdx]

While that will work fine, a more built-in feature would require editor and runtime changes. A sequence could have the option to play automatically, but would need UI in setup mode to configure that and runtime code to apply the sequence. That is a good idea, but we won't be able to get to it in the short term. I've added an issue to implement it:
https://github.com/EsotericSoftware/spine-editor/issues/678

Thanks will take a look at auto creating animations (and also canceling animations if we switch from an animated attachment to a non-animated attachment.)

Thanks for adding the issue for the built-in feature, appreciated!

If I was going to do a patch/edit to the runtime instead of creating animations, where would you suggest I look? I imagining where I add a skin, but then forcing an animation if it's a sequence in the runtime. I guess this might just be similar to using the API to loop and assign animations, but in the runtime itself.

To hack the runtime, probably you don't want to use an animation. The renderer already loops over the slots, checks if there's an attachment, and draws it. Edit the renderer where it finds a mesh or region attachment, if the attachment has a sequence then set the slot's sequence index similar to what SequenceTimeline does.

You'll need a time reference, so you know what time the sequence is at. You could use wall time, assuming your sequence loops.

17 дней спустя

Great, thanks for the ideas for the hack while we await the full implementation.


Here is my simple hack (added for Mesh and RegionAttachment in SkeletonRenderer.draw():

For example for Mesh:

} else if (attachment instanceof MeshAttachment) {

  // Automatic sequence looping
  if (attachment.sequence) {
    // Length of animation in frames
    let count = attachment.sequence.regions.length;
    let index = Math.round(currentTime / frameTime);
    index %= count;
    slot.sequenceIndex = index;
  }

currentTime = Date.now()
frameTime = (1/frameRate) (e.g. in our case 1/5, since we are standardizing on 5fps, until the new functionality is in, which will allow for different default fps, looping styles, etc. per sequence in the editor.)

This is working for us, automatically playing and looping sequences, but let us know if there is anything else to watch out for.

That looks like a perfectly fine solution! You could even do it before calling draw, by looping over the slots yourself. That way you don't need to modify the runtime.

Ah, good suggestion! Thanks!