[request] Please allow rendering loop-cycles above the first cycle without the need to copy the cycle in the timeline

[bencresty]

When creating animationloops for video normally it's fine just to render the frames to an image sequence and loop this in other software.

However, when using physics in the animation this is not possible, because during this single loop cycle frames the effect of physics kick in and they aren't finished at the end of the frame range (loop-cycle), but continue in the next loop-cycle.

When the animation is done right this, however, is no issue, when we duplicate all keyframes in our animation so that we have two loop-cycles in our spine file. If we then render only the second half of the animation to an image sequence (so only the second loop-cycle) everything should seamlessly loop again, even with the physics.

However, this is obviously extra work everytime we do this (copy all the frames of all bones etc.), is prone to errors and makes working with Spine less flexible, because when we now want to change something we need to do everything in two places (two 'physically' different loop cycles on the timeline). Also we have redundant duplicate data in the file, which shouldn't be necesary.

---

Suggestion/request: It would be really helpful if, instead of needing to copy all frames on each and every looping animation and having above described issues, Spine's exporter could assume that every timeline is endlessly looping and allow us to enter ANY frame range in the exporter. So basically just like how the timeline in the editor already works (always looping).

So let's say our timeline contains a single loop-cycle of 100 frames and we would like to render the second loop-cycle to have looping physics. We now only need to enter frame 101 to 200 in the exporter. Than Spine starts playing the animation from fr 0 to 100 internally without exporting (only to have the physics calculating and have everything in the right state for frame 101) and than keeps looping the animation like the editor does while keeping track of the incremental frame number. So after frame 100 it loops from frame 0 again, but the exporter knows the current real framenumber is 101 now and so on. So if we want to render frame 101 to 200 it renders the SECOND loop-cycle of a looping animation only, eventhough our timeline itself is just a single loop from 0 to 100. So than the exporter works just like how a loop-cycle would look when we would just hit play on the timeline and look at it when it went back to start for the first time.

Hope this makes sense. This would be super helpful!!

Thanks for considering!

[NathanSweet]

In the export settings you should be able to use Animation repeat to do this, but I see the animation resets for each repeat. Now that we have physics that doesn't make sense, so we'll use this issue to track fixing that.

Being able to specify frames outside the range of actual frames in the animation is a bit more complex. It could be more powerful, but I have a feeling Animation repeat may be sufficient for your use case.

Don't miss the Warm up setting, so you can have the animation run before your export starts to prime the physics location.

[bencresty]

.

[bencresty]

Thanks for the info @NathanSweet , although some things aren't really clear to me;

In the export settings you should be able to use Animation repeat to do this,

Not sure what exactly you mean with 'Animation repeat' in the export setting. When I look in the export dialog I don't see any setting named or looking like that. What am I missing? Where should I look?

but I see the animation resets for each repeat. Now that we have physics that doesn't make sense, so we'll use this issue to track fixing that.

Thanks! That's super apprecatied.

Being able to specify frames outside the range of actual frames in the animation is a bit more complex. It could be more powerful, but I have a feeling Animation repeat may be sufficient for your use case.

Unfortunately can't check, because so far I cannot find that setting (see above).

Don't miss the Warm up setting, so you can have the animation run before your export starts to prime the physics location.

I do see this 'Warm up' setting in the export dialog. But to me it's not sure what exactly this does, how this is supposed to work and what these numbers are even representing. They don't seem to be frames as they only go to 6 here (while the animation is currently around 300 frames), which is obviously too little to 'preload' physics. If that's what it's supposed to do. What exactly is this setting for, how does this work?

Unfortunately the Spine documentation (https://esotericsoftware.com/spine-editor-documentation), which is super for what is in there, seems to be pretty outdated (not updated since v4?) and doesn't show anything about the features you mention. The other day I also was looking for things in the Spine format in there, but also that was not there. Same as image sequences I believe. It would be nice and helpful if the Spine manual could be updated to the latest Spine version someday. As it's a real great resource for such things!

[misaki-eymard]

@bencresty Animation repeat is an option available for GIF, APNG, AWEBP, AVI, MOV, and WEBM:

While it is true that we have not updated our user guide enough, the added options already have tooltips that appear when you hover your mouse over them, and their basic usage can be found there:

By the way, the Warm up has already been mentioned in a couple of sections of the user guide: https://esotericsoftware.com/spine-physics-constraints#Warm-Up https://esotericsoftware.com/spine-export#Warm-Up

Animation repeat is also mentioned on the Export page: https://esotericsoftware.com/spine-export#Animation-repeat

We appreciate your suggestions and problem reports, but this is not the place to answer questions. We want to make it as easy as possible to review issues, so please post them in the forum: https://esotericsoftware.com/forum/

[bencresty]

@bencresty Animation repeat is an option available for GIF, APNG, AWEBP, AVI, MOV, and WEBM:

But not with image sequences. Which is what I'm talking about.

For the rest, I see you responded while I was adressing Nathan. Also in your other recent reactions towards me last days, you come accross as overly and non-fitting defensive and as if you place yourself above me, which I think is very inappropriate and not suiting to the contents of my posts nor actions/behaviour. You act like I'm 'just posting' something here, as if I'm a beginner, which is in no way the case. I'm by no means a beginner and I'm also clearly not just asking questions, but rightfully pointing out valid things missing in the manual (which shouldn't be necesary), issues in Spine and feature requests coming from a long time professional user. Github is the place for this. I kindly ask you to stop treating me like a child and act professionally and on the same level instead of above me.

[badlogic]

@bencresty nobody is placing themselves above you, especially not Misaki. Take into account that the team is multi-national. In fact, we only have two native speakers.

Misaki is right that this kind of inquiry should go on the forum. It is for us to decide where users should post their feedback and questions, as we are the ones who have to slot that into our processes. The issue tracker is reserved for things that we actually plan on doing. Issues result from a discussion on the forum between us and users, where we brain storm if and what needs to be done. Only if we deem it a valuable addition is an issue created on the tracker.

As for professionalism:

For the rest, I see you responded while I was adressing Nathan.

Misaki is as much a part of the team as anyone else, and if a team member believes they have something valuable to contribute, it is their right, and actually expected, that they contribute to a conversation. Nobody has treated you like a child including Misaki, who to her best of her abilities tries to provide helpful information and input.

Misaki's words weigh equally heavy as Nate's words, if she asks you to post things on the forum.

[NathanSweet]

As Mario mentioned, the entire Spine team works together. I apologize if you felt Misaki's responses came across as dismissive, but I can 100% guarantee that was not the intention. She has everyone's best interests at heart.

I think there is some confusion due to us allowing users to submit issues directly to the Spine editor tracker, but almost no users do that. Instead, almost all issues are created by us as a result of forum discussion. This works well, as the forum is a more comfortable place for discussion and we create issues as needed according to our internal guidelines. Misaki's suggestions to use the forum stem from that workflow.

By first discussing an issue, we can ensure understanding on both user and dev sides, and only then create an issue (linking to the forum discussion). This is better, so discussion doesn't spill over into the tracker. It ensures all tracker issues are curated and task focused, not cluttered with back and forth discussion about what the issue is exactly, what solutions might be, workarounds, and other similar things.

Given that, we'll probably (pending more internal discussion) disable user submitted issues on the editor tracker. Please take no offense, your issues are great and a big help to improving Spine, it's just a better workflow to start through the forum. Many software forums are a blackhole for user issues, but not ours! We put a lot of effort into staying on top of our forum. I hope that you will continue to post your issues, just to the forum rather than to the tracker.

That out of the way, we can continue with this issue!

---

I think repeat is disabled for image sequence exports because we didn't expect someone would want many copies of the same images -- they would be identical copies before we added physics. However, with physics it makes sense to allow repeat for all export types, so we'll do that.

Warm up runs the whole animation X times before starting the exporting. This way your physics is in motion on the first frame of export.

For now maybe you can use the repeat setting with video to bring the frames into another application? Often it's more convenient to bring over a single video file rather than many images.

Documentation for the latest features is severely lacking, sorry. We sacrificed it to push physics out but we haven't forgotten! It's a WIP.