I guess, the title is quite self explaining. Currently, you can select an area to loop in the dopesheet for editing purposes. Sadly, this is only valid there, for obviouse reasons. On the other hand it would be great to have exactly this as an attribute to the animation, where I can set a start point for the loop and the animation is played from the start and loops, after reaching the end, not from the beginning, but the looping point.
This is a simple feature, which opens a lot of opportunities. I'm using Spine to animate user interfaces and with this feature, I would only need to trigger the entry animation and can embed the idle animation for the button within this animation. Currently, I need to wait for the entry animation to end and then trigger the idle animation. I would imagine, that this use case is applicable to other tasks as well, like something exploding on a character and then looping a dust cloud and such.
This approach is available for WAV files, which contain a meta data field to set a time stamp for looping the audio. Unity for example is able to read and interpret this field and loop the audio as expected.
Feature Request: Animation Looping
- Đã chỉnh sửa
You can do this at runtime by setting TrackEntry animationStart (and TrackEntry animationEnd). We don't have a way to set this up in the editor though. We'll consider how that could be done, but it would have to interact reasonably with the runtime API.
In that case, I need to hard code the animationStart, where I think, this is something the UI artist should decide. Both the if and the when of the cycling. Technically, I would expect an attribute, like color and others, to be set on the animation, either by a dedicated button or simply by entering the requested frame number, which defaults to frame zero = current behaviour.
It does make sense for the animator to decide, but animation playback at runtime is very flexible. The runtime API allows playback to be customized in ways that would not be possible to define in the Spine editor. A workaround could be name/value pairs (we have planned) to allow arbitrary data to be stored for an animation, then code at runtime would know how to interpret the values. A more direct solution would be to allow this kind of playback customization in the editor. At runtime we would need to apply the right logic and come up with a way to not conflict with use of the runtime API, possibly by disallowing API changes or disabling the editor customization if API changes are made.
I understand, what you say and more important the why behind, but I would disagree in this case. The beauty here is, that the unaltered default behaviour already would be the same, as the current behaviour, there is no change. The difference would only happen, if one alters the loop point, which would be part of a new editor version as well as a new runtime version. Or is the API and feature set ment to be sizzled in stone from now on?
I've done this before on anim side but not code - I would put in event keys to define the looping start + end, which are then picked up in code - so the anim plays the intro animation and then loops infinitely after it passed the LoopStart event key. Anything after the LoopEnd key would be an outro animation.
It would be ace to have a more in-depth feature in Spine for this in future 