Cycles in animation

Open, WishlistPublic

Actions

is this for looping?

if so, i hope someone will pick this up,this is a huge workflow enhancement,but is also related to a redesign of the timeline that ScottyP did in another phabricator thread.

One of the students chose the task for his practice task. Please add your ideas about what you think should be implemented here! :)

I think it would be good to see how this fits in to the big picture when we do the UI. Here are the mockups for the original discussion. https://phabricator.kde.org/M2

yes

there might be some discussion needed still,you can often find me on IRC for an animator's input.
The following will be my initial thoughts but can be downscaled to make it more manageable or expanded to make it more feature complete. I have no idea how big this project needs to be for the student,so it will need discussion.

Cycling the selected frames will need a symbol or sign of some sort Scottyp already did an attempt ,but it needs more focus probably.

the cycled frames need to be highlighted in some fashion,maybe with color,maybe with a symbol. There are customized colors to consider so color might not be the best,unless you give a BORDER color only,that might work. The cycles after the initial cycle needs a horizontal line or repeating pattern (dotted line, striped line) that can show you each cycle by just looking at the frames. Maybe even numbered by cycle if this would be possible?

Also we need to know if you will for starters only limit to INFINITE cycles ,till it reaches next new frame. or if you can specify an end.
If you can specifiy say 3 cycles, we would also need to implement 'EMPTY frames' . Right now a frame has an infinite duration till the next frame. We would need to be able to have a certain limited duration for a frame. The duration can be indicated by a straight horizontal line. Where the line stops, the frame duration stops.

This is the same idea for cycles,but the line for cycles needs to be different so you can distinguish it from the duration lines of a normal frame.

The way to initialize a cycle is probably best by selecting a range,and giving input for the length.
Cycles of 3
cycles of 5
cycles of INFINITE should also be possible,so you can just break it of manually by adding a new frame after the cycle.

These cycles should at any time be able to be changed in length or modified or deleted.

these are a few of the thoughts i had,i may have many more but you can contact me on irc.

Yes I agree with a lot of @Bollebib points. If we are doing a "cycle", we need to have some concept of a set of frames to be repeated. Right now everything is just one frame at a time. With adding the idea of cycles, there might be a lot of work needed behind the scenes to support that concept like empty frames and a different display for a group of frames.

Colors won't work, so we could do empty frames that could help, or potentially putting a border around an entire group. I am not sure what direction @dkazakov
has and the work that will be involved.

While hacking something together might work for just doing the cycles part, my fear is that it will make the whole UI harder to use

Hey everyone, I just wanted to share a possible design mock-up for animation cycles that I put together.

I agree with @scottpetrovic and @Bollebib on most points, and I also have some ideas that are influenced from the world of audio clip and midi clip looping features. Let me know if I should post this to https://phabricator.kde.org/M2 also. First here's the mock-up:

The basic idea is that a range of animation Frames can be converted into a Cycle - a single, labeled unit on the timeline that can be moved around and/or extended infinitely in either direction.

Clicking on the center of the cycle and dragging would move it around the timeline, while clicking near the edges of the cycle and dragging would extend the length of the (looping) cycle. The "loop points" of the cycle can be visualized with a simple, dashed line between the last and first frame. The Cycle in the mock-up is called "Cycle 1" (can be renamed) and is doing two full loops, but could also do more loops (or partial loops) in either direction.

For editing, the animator would be able to convert the Cycle back into Frames, which would then be edited normally.

(PS: The set of frames that I turned into a cycle in the mock-up would probably pop like hell in a real animation, but I didn't think about that until half-way through the editing process. Haha.)

Let me know what you think.

Thanks for the mockup, Emmet. Based on it, we continued discussing the feature with Bollebib today. We gathered some requirements and possible solutions.

Our users should be able to:

• mark a cycle on the timeline
• change the range frames which are repeated
• edit the frames of a cycle. Changes should be reflected in the repeats.
• convert repeats into actual keyframes or clone frames
• draw on repeats without breaking the cycle due to automatic keyframing (option in autokey?)

I propose the following behavior:

• User can select a (continuous) range on the timeline, open the context menu and select "Create cycle".
  • The begin and end frames of the selection define the range of the cycle.
  • If there is already a cycle within or overlapping with the selection, it is replaced by the new one. This makes it easy to modify the cycled range.
• The cycle is displayed on the timeline in a way that clearly communicates it as one.
• The cycle is repeated until the next keyframe (just like we currently extend holds).
• The repeats are displayed in a way that communicates that they are repeats, but still shows where the repeated keyframes land on (e.g. a ghostly version of each keyframe, or a small rectangle for each).
• If the user needs to break out of a cycle for some frames and continue after them, clone frames can be used.

Here is a quick mockup for how the above might look like. The exact visualization of course needs further discussion.

Another approach, which we discussed would be to treat cycles as group-like objects. They could be manipulated as a whole (just like in Emmet's mockup) or "entered" for editing the individual keyframes within (like groups in vector graphics). This seems to me like adding complexity for little gain to users, but is a possible alternative.

Our users should be able to:

• mark a cycle on the timeline
• change the range frames which are repeated
• edit the frames of a cycle. Changes should be reflected in the repeats.
• convert repeats into actual keyframes or clone frames
• draw on repeats without breaking the cycle due to automatic keyframing (option in autokey?)

Sounds good. Does "draw on repeats" mean that if you drawn on a "ghost" of a frame it will also modify the original frame and all other ghosts? That sounds convenient, if I'm understanding it right.

The cycle is repeated until the next keyframe (just like we currently extend holds).

Great idea! I didn't think of that, but it makes a lot of sense.

If the user needs to break out of a cycle for some frames and continue after them, clone frames can be used.

Makes sense to me!

At any rate there needs to be some mechanism for partial cycles; jumping out of a cycle early, but also jumping into a cycle in my opinion.

For example, if someone animates a character run cycle (let's say it's a 6 frame loop), if they want to animate the character going from standing > start running > run cycle > stop running > standing, they might not want to the cycle at frame 1. In other words, imagine a sequence of frames like:

A B C D E 4 5 6 ,1 2 3 4 5 6, 1 2 3 4 5 6 ,1 2 3 4 5 6 ,1 2 W X Y Z

Where A~E are the "standing into running" sequence, 1~6 is the run cycle, W~Z is the "running to standing" sequence. I've marked the cycle's loop points with commas. This leaves a partial loop at both the beginning and the end of the run cycle. This is why I was thinking they could 'drag' the left side of the cycle to the left to extend the loop backwards as well - so the user can jump in or out of the cycle at any point.

Here is a quick mockup for how the above might look like. The exact visualization of course needs further discussion.

I like it! It's certainly less opaque than my mock-up and the capsule-shape really screams "cycle". So I think you're on the right track here!

Another approach, which we discussed would be to treat cycles as group-like objects. They could be manipulated as a whole (just like in Emmet's mockup) or "entered" for editing the individual keyframes within (like groups in vector graphics). This seems to me like adding complexity for little gain to users, but is a possible alternative.

I agree. That's more complex than this needs to be. Moving cycles as a unit is something that could still exist even in your design as an option in a right-click context menu or something like that.

I assume in your example the run cycle is drawn somewhere outside the range of frames you describe here.

Not exactly. In my example the actual cycle would be just after the first comma. Here's the actual, drawn cycle shown in brackets.

A B C D E 4 5 6 ,[1 2 3 4 5 6], 1 2 3 4 5 6 ,1 2 3 4 5 6 ,1 2 W X Y Z

So the original cycle (a character's run loop) is drawn on the frames within the bracket, while every other numbered frame is a ghost/clone/repeat from the original. The point being that repeats frames aren't just useful after a cycle, but are also just as useful and practical before a cycle, in my opinion.

With my proposal the first six frames after E would then be clones of the original cycle's frames, marked as a new cycle. This would make them repeat until the next keyframe (W). I can see how this might be a less than ideal workflow in this use-case if the user wants to adjust the cycle.

Right now your design elegantly takes care of repeats that come after the original cycle but it would force the animator to jump into every cycle on frame one. (Of course, with the obvious workaround being that they could just copy some frames out of the cycle and paste them before the cycle starts. But that's not really ideal.) This is why I had included the concept of dragging from the edges of the cycle to extend it in either direction. Automatically extending the cycle until the next keyframe is a great idea, but I don't think it precludes the need for manual control, especially in the case where you want the cycle to 'extend backwards' from the cycle's first frame.

Edit: I should also say that, in the abstract, you could just start the cycle from "4" like this:

A B C D E [4 5 6 1 2 3], 4 5 6 1 2 3, 4 5 6 1 2 3, 4 5 6 1 2 W X Y Z

This works fine, of course. However it might cause friction with the logical key poses of the animation. For instance, if instead of being a character run animation, this was an animation of a frog hopping, it probably would make sense for the first frame of your cycle to start with the frogs scrunching up in anticipation of jumping instead of starting the cycle on one of the mid-air frames. It's possible that I'm just overthinking it, I'd be curious to hear what @Bollebib thinks.

Anyway, this isn't a deal-breaker or an insurmountable problem or anything like that, but it's possibly worth considering! If it's even worth addressing at all, it's probably something that could be taken care of down the road.

Aside from that minor nitpick, I think we have a pretty solid foundation here.

Hi, @jounip!

• User can select a (continuous) range on the timeline, open the context menu and select "Create cycle".

I have a few questions that might help to clarify how the cycles will work:

1. The user selects entire "cycle" and moves it using D&D operation. What happens? [I guess the the whole cycle should be offset]
2. The user select right half of the "cycle" and moves it using D&D operation. What happens? [I guess the cycle should be resized]
3. The user presses "Insert frame and offset" inside the cycle. What happens? [I guess the cycle should be resized (extended)]
4. The user presses "Remove frame and pull" inside the cycle. What happens? [I guess the cycle should be resized (shrunk)]

My main concern for the cycles is making sure these controls don't start overlapping. If we start overlapping any existing items, this could be difficult to use fast. We will only be able to change and move things from a right-click menu since there selecting it on the timeline will be difficult (are we selecting the frame contents or cycle?). So far the two versions of the mockups I have seen have overlapping UI elements between the frame and the cycle which is going to make manipulating more difficult.

One thought is that a frame currently take up the entire square. If a cycle is added, The start/end elements could possibly take up the bottom 1/2 of the frame with an arrow/icon denoting the cycle part. That area will be able to have dragging/dropping functionality for moving the cycle around. If you right click on the area we could have cycles helper functions similar to our right-click options for frames.

Let me know if that makes sense or you want a wireframe with my thought.

Here is an idea I had about how the UI and UX would work with animation cycles. Not sure what people thought.

In T3496#163171, @scottpetrovic wrote:

Here is an idea I had about how the UI and UX would work with animation cycles. Not sure what people thought.

that could work

i'll have to see it as an actual mockup tho and if it fits with what Jouni currently has