Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] Implement Loop Selected Frames #243

Open
ghost opened this issue Feb 10, 2014 · 3 comments
Open

[Request] Implement Loop Selected Frames #243

ghost opened this issue Feb 10, 2014 · 3 comments

Comments

@ghost
Copy link

ghost commented Feb 10, 2014

By @sfepa

This function can save a lot of time when you need repeating animated details in complicated scenes, for example snow, rain, flag, smoke etc.
Instead of copying frames manually we could select them and define as loop.

@chchwy chchwy added the request label Feb 10, 2014
@blurymind
Copy link

this can be implemented as frame "instances" or "clones" - similarily to how toonboom and flash handles it. This way editing a clone, affects all the other clones. But you can still create a brand new frame by copying from a clone.

@davidlamhauge
Copy link
Contributor

Will this be taken care of in #1106 , or is there more to it?

@Jose-Moreno
Copy link
Member

@davidlamhauge Unfortunately there's more to it, as I wrote on Discord a few weeks ago in the #feature-requests channel, an later on the Google drive nested timeline proposal there are always two main expected use cases for loops: timeline dependent cycles and timeline-independent cycles.

The issue you referenced would be able to cover the first case and address the OP suggestion I think. But the second comment would go more in line with the second use case, and would require the "nested" images container I spoke of.
This container can be made to be manipulated independently from the main timeline, and looped "indefinitely" while using global setting to control the exposure of the nested "timeline" over the main timeline. In order to cycle the keyframe exposures it would use "clones" or instances that always keep refering to the original drawing resources (the raw PNG's) for a defined range of frames that the user sets.

That said, once 1106 is merged I think we could close this issue and open a specific issue for the other case, since that one depends on a different set of requirements to be met before being fulfilled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants