Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[Request] Implement Flipping / Rolling Feature #978
This is one of the features that are on the request roadmap and it's been requested a few more times.
In traditional animation Flipping & Rolling are two similar techniques that allow the animator to quickly preview their current animation work by flipping ( jump between the first, last and inbetween drawing of an action) or rolling (preview drawings in ordered sequence flipping with all your available fingers).
Explanation of Flipping Techniques
In order to mimic this behavior in a digital environment timeline this functionality should aim to modify the playback behavior as it should be based upon the current drawing / frame container that is being edited, that is, where the playback scrub is located at the moment of activating the function.
I have to note this functionality is semantically different from the Range function as well how its applied during a job. Whereas the current Range function allows you to preview a portion of the timeline from start to end including every frame in the range (in a way this would fulfill the stack flipping technique), the inbetween flipping and roll flipping functions have to behave differently to allow the animator to see the only the drawing(s) (normally keys or main drawings) behind and /or in front but always coming back to the currently edited drawing.
In the sense of previewing only the keyframe drawings, we have a similar behavior exhibited by the "onion skin toggle match keyframes" command (the little diamond button on the timeline)
For reference you can read about TVPaint's "Flip" function panel: https://www.tvpaint.com/doc/tvp11/index.php?id=lesson-tradigital-animation-advanced-flip-presentation
I think we can extend the current range function so it can Ideally contain the additional Flipping & Rolling behaviors. Pencil2D's own inbetween flipping, roll flipping and stack rolling should comply with the following criteria (Updated 02/05/2019):
Hmm given that you say that flipping and rolling alters the playback of the timeline in ways it was never supposed to, maybe it would be better to contain this in a new or multiple widgets? say for example one could generate a flip window with certain settings, it would be like a preview window but with its own timeline, fps etc...
Otherwise we might have to hack the timeline to make it work with this, things such as making the scrubber jump between certain "key" frames with in-betweens could take some work and one would have to toggle it on and off but what if you want both normal playback and flip?
This could be an opportunity to make the timeline more dynamic, so we could reuse the base but alter its behaviour depending on what we need it to do.
By selecting the frames you want to flip through, via our current timeline, the flip timeline would be based on that, so the flip timeline would look like this
one could alternatively use the keyframe position manager (found in the config window that appears when you create a flip window) shown above to set their custom flip order.
Things about the flip timeline:
Things to be considered:
it's essentially a preview window on steroids.
This was referenced
Nov 23, 2018
@CandyFace sorry I never really replied to your proposals, at that time I thought they were great. Today @davidlamhauge implementation has been merged and now I think both of us were probably over-thinking this feature a bit too much.
Since the flip feature is meant for a quick hands-on preview while your working, getting a different viewer or even abusing the range feature (which I thought it would work as a visual cue), was simply too much. The current implementation is really practical and it works as intended.
I've updated the requirements on the original post and although some of the initial ones were fulfilled successfully, I'd like us to discuss the ones remaining marked as "pending discussion". I've put my personal input as a side note on each but depending on what all of you comment, we can consider this fulfilled and close it or wait to implement the remaining tasks in a future enhancement patch tied to this same issue and close it once those are done.
Thanks again for everyone that contributed to this, we're one step closer to our goal for sure!