A guest stopped by the IRC to tell me that he wanted animation support for vector layers (and all layers).
I told him that I'm sure that's something many users want, though it's a big job and will have to come after improving traditional animation. =]

@Bollebib also suggested adding more Layers Docker functionality to the Timeline Docker.

Would it be possible to pickwalk throug the layers in the timeline docker? If you press up or down in de timeline docker you change the selected frame, but it would be handy if you could walk through the layers just as in the layers docker. And what would other users think of "isolate selected layer" so that you can view the contents of the layer while pickwalking through the layers.
The function would only make the layer visible that is selected, and if you select another layer (by mouse selecting or pickwalking in the layers docker or timeline docker), than that layer is going to be the only layer that is visible.

Or is this function already available? If so, from now on forth I shall readeth the damn manual, whilst also making my sincerest apologies.

@hurgar You can cycle up and down layers using the "Page Up" and "Page Down" keys. =]

One of the requests from @Bollebib on our list is to create a version of this that doesn't enter groups. Is that something you'd find useful to?

Thank you for your comment. My shortcuts are different, so if I press the alt-[ and alt-] combo it works! Yes. i should have read the manual.

I only use the pickwalking the layers so I can isolate the layer to see what drawing the layer holds ( i made a keyboard shortcut for isolating the layer ) and if I want to make adjustments or add something to that drawing. So, I only want to pickwalk through paint layers. I can see it could be handy to only pickwalk throug groups and not the contents of the group. Perhaps if the group is collapsed, than the pickwalk wil not go through the content of the group, and if the group is expanded than you would pickwalk through the contents. So it would be a pure visual, what you see is what you can pickwalk.

i think if it was only visual that would also have limitations and annoyances

best that its probably just a different function

for going example up and down is pg up or pf down

and then do shift+pg or shift + pg down to only do groups (but you would need to set this yourself)

1. A small little request may be that using mouse scroll no longer goes from frame to frame but that it scrolls the timeline up or down

This behavior is more expected

You can always to shift + mouse wheel to do the current implementation in stead? (or make it configurable)

2. a larger request would be to have a folder with frame contents show the frame ticks as a whole in the folder layer

This way you can remove a frame in the folder later, which would then remove it from multiple layers if there are several layers beneath it with frame contents

Moving the frames around would also work.

In essence it would work like the summarize dope sheet feature from Blender

here you can see on top the contents collated from all the layers below and you can edit them, so the frames would move around, but multiples at once

I may have missed it but this is something related to animation and that Tyyppi knows about, maybe it should be included here.

Frames should get an ID so they can be reused as a clone. These clones should update into version each of itself. This will make reusing frames easier and the workload lighter for some kinds of animation, this is lightly connected to cycles, but not necessarily so.

You then need a way to break that link and make it a unique frame.

So, the clone animation stuff is actually already very far in progress (it's in the cycles patch), but tyyppi never finished it. There's some leftover bugs with it.

so we ALMOST have cycles

would be good if that could get finished completely

Timeline Docker: Time Change Shouldn't Mark Document as "Changed" (https://bugs.kde.org/show_bug.cgi?id=409443)

Looked into this today. The problem seems to be that Krita uses a KDE library's undo-redo stack (KUndo2Stack) to determine whether the document has seen significant changes. Since users want to undo and redo frame index changes, those commands being added to the stack marks the document as dirty.

If that's the case, here are some possible solutions:

1. Extend KUndo2Stack and KUndo2Command with Krita specific functionality. Add a m_dirtiesFile flag to commands which helps the undostack determine if the stack is still technically clean. When a hypothetical KisUndoStack adds a new command to the stack, if the last command on the stack is the cleanIndex, it will use setClean on the next index if the m_dirtiesFile is set to false. This way is probably the most proper way, but adds more complication to the type hierarchy...
2. Create a wrapper for the KUndo2Stack KisUndoStackWrapper that handles this task automatically by hooking into KUndo2Stack's signals. This way is probably less invasive on existing UndoRedo commands, but the indirect nature of it makes it more error prone.
3. Find a way to access the undostack from the frame change undo/redo command itself (perhaps passing in a document weak-pointer) and check if the document is clean before / after do-undo. Basically, the action itself would manually undo the dirty flag after the action is committed. This could work but would need to be redone whenever any other non-changing undo-redo task is made.
4. Remove undo - redo for frame change operations (I don't like this one, but it's worth mentioning.)

I'll bring this up @ the next meeting.

so we ALMOST have cycles

would be good if that could get finished completely

@Bollebib I agree with this, I also want to prioritize getting this in there ASAP especially before working on even more animation features if we can. Maybe I should bring it up next meeting as well.

Is there any chance of getting composition docker export to work with animation? this would be good for more powerful exporting options and layer control for those exported PNGS or movies

You could prepare the seperated animations for export , and update each composition and then export. for use in another pogram or to share with a team.

-You would ofcourse need an option to chose between normal export or animation export ,just in case both types of layers are available
maybe 2 options? 'Export Compositions' and 'Export Frame Compositions'

-Would be good if filters and masks also can be rememberred by the docker.
-Reordering Compositions or even grouping them for easier management would be nice too. Right now you cant change the order, which limits the compositions you can do for animation or otherwise

@Bollebib I think doing that wouldn't be too difficult but would require a new Export UI for the compositions docker to accommodate for more advanced settings (kind of like the existing Animation Exporter UI?)

The filters thing is arguably easier and the fact it doesn't store the state I would consider a bug. There's text-based metadata in every filter layer so saving the settings applied to a filter should be relatively trivial. (famous last words. :) )

Out of curiosity though, @Bollebib , do you think there's potential overlap between the features of the current compositions docker and the proposed storyboard docker T12819 that are worth noting? It seems to me like the original intention of this dockers design was to manage multiple compositions in one krita file, which seems to overlap the concept of storyboarding in general. It might be good to unify the vision of this docker with the proposed storyboard docker perhaps?

Hi, @emmetoneill!

I've got a reply from @Bollebib about your implementation of "Selection next/prev sibling" feature. He reports it works as expected. The only worry he has is that he wanted to use it in conjunction with this feature that is not yet implemented :) https://bugs.kde.org/show_bug.cgi?id=377468

In T12769#225732, @eoinoneill wrote:

@Bollebib I think doing that wouldn't be too difficult but would require a new Export UI for the compositions docker to accommodate for more advanced settings (kind of like the existing Animation Exporter UI?)

The filters thing is arguably easier and the fact it doesn't store the state I would consider a bug. There's text-based metadata in every filter layer so saving the settings applied to a filter should be relatively trivial. (famous last words. :) )

Out of curiosity though, @Bollebib , do you think there's potential overlap between the features of the current compositions docker and the proposed storyboard docker T12819 that are worth noting? It seems to me like the original intention of this dockers design was to manage multiple compositions in one krita file, which seems to overlap the concept of storyboarding in general. It might be good to unify the vision of this docker with the proposed storyboard docker perhaps?

-yes , a Export UI will be necessary probably. maybe @scottpetrovic can offer ideas for this
-The filters and masks, if its trivial that would be good!
-i dont think the composition has much to do with storyboarding. Storyboarding is a storytelling tool, while compositions is for handling art (or animations) layers to create export "templates" in a sense.

Would it be possible to have a new function? "update selected to all compostitions"

For example when you create a new background or character -> it will not be in ANY of the old compositions which is good.
BUT you could

Select layer (or range) ->"update selected to all compostitions"
Select layer (or range) ->"update selected to active compostitions" (if you unchecked some)

This would be a way to speed up adding a new layer to all compositions if you KNOW that it is needed in all of them (i have had files with +10 compositions)

In T12769#225945, @dkazakov wrote:

Hi, @emmetoneill!

I've got a reply from @Bollebib about your implementation of "Selection next/prev sibling" feature. He reports it works as expected. The only worry he has is that he wanted to use it in conjunction with this feature that is not yet implemented :) https://bugs.kde.org/show_bug.cgi?id=377468

Yes it works as i expected for the groups

I hadnt expected that it would work for layers IN a group, but for now that seems okay behaviour. I will need to test more in production to fully decide if all works well, but for now it seems great!

The other feature that Dmitry mentions is tangentially related, because it also works with groups and selection. I just wanted to caution that they both should work logically together

i saw this proposal

I also remembered an older wish of mine for animation while filling in the Animation Survey (i hadnt seen it)

ID Color library

This mostly useful for celshading only (probably?) The idea is to have colors per character that you setup, you use a color to do the body, face, maybe even shadows and highlights, but then you could click on that color and change it. Changing these values would change ALL frames where that color has been used.

"Misc: Multi-frame operations and filters. " does this mean you will try and make "apply to all frames" possible? If so that would be great!
Being able to apply filters AND transformations to all frames would be a big productivity increase. Maybe tho there SHOULD be a way to interrupt the operation to prevent krita from hanging if it takes too long....

In T12769#226607, @Bollebib wrote:

i saw this proposal

and i mainly agree with it , if we could eliminate that docker that would maybe be good.

I've seen that too and I agree with it. There's no point having two dockers that are so tightly coupled--you can't ever use one without the other.
It's something that I need to bring up with the group to make sure that they're ok with doing it.

I also remembered an older wish of mine for animation while filling in the Animation Survey (i hadnt seen it)

ID Color library

This mostly useful for celshading only (probably?) The idea is to have colors per character that you setup, you use a color to do the body, face, maybe even shadows and highlights, but then you could click on that color and change it. Changing these values would change ALL frames where that color has been used.

Yeah I see. I've seen keyframes and illustration layout like this many time, with black for general lines, blue for shadow cels, yellow for highlights, etc.

What you're describing sounds more-or-less the same as index colors, which is something that could also be very useful for pixel art creation, but is also something that might be a bigger project and I think something that Krita has avoided handling so far.
This is also something that might need a bit of broad convincing to make happen, and it's also probably a bigger job because we'd have to make a new image type or color space. (I think. I'm not 100% sure though.)

"Misc: Multi-frame operations and filters. " does this mean you will try and make "apply to all frames" possible? If so that would be great!

Being able to apply filters AND transformations to all frames would be a big productivity increase. Maybe tho there SHOULD be a way to interrupt the operation to prevent krita from hanging if it takes too long....

Well, that's the idea at least. I can't promise that we'll be able to do it for absolutely everything in a reasonable span of time, but the goal is to prevent animators from needing to hit Ctrl+F or whatever on every. single. frame. ;]

Can I also ask you for input on this: https://bugs.kde.org/show_bug.cgi?id=376890

This bug report is suggesting that onion skins should be hidden for anything that isn't current pinned to the timeline.
The idea being, I guess, that the layers that you're currently animating on are likely pinned, and those are the ones that you care about seeing the onion skins for.
Do you agree with hiding onion skins of unpinned layers? Or would that hurt your workflow?

Finally, we have quite a few things on our list already, and It's likely to grow when I comb through the survey and various forums.
If you have any suggestions for which things we should prioritize or which changes would have the biggest positive effect on your workflow, we'd love to know so we can make sure to tackle those as soon as we can.

Thanks again for all of your input, @Bollebib

• yes for pixel art that could be great too!

• https://bugs.kde.org/show_bug.cgi?id=376890 i can see the reasoning for it. I have nothing against it for now, makes sense. Though in practice maybe i will run into issues with it , for now i dont think so? especially with all layers being in the timeline by default.

1)Timeline Docker: Animation cycles. In-progress by @jounip

2)Timeline Docker: Add more Layers Docker functionality. @Bollebib Needs more info.

3)Misc: "Isolate Active Layer" (rename) & "Isolate Active Group" (new isolation mode). https://bugs.kde.org/show_bug.cgi?id=377468

4)Misc: Multi-frame operations and filters. https://bugs.kde.org/show_bug.cgi?id=406327 https://bugs.kde.org/show_bug.cgi?id=373305

5)Render Animation: Compositions Docker: Render Animations from Compositions https://bugs.kde.org/show_bug.cgi?id=404245

PREFERABLY (if possible) with some of the easy suggested tweaks to the composition dockers i have mentioned , like being able to reorder the list (now impossible). If not then the base functionality would already be welcome

6)Tools: "Speed based smooth dropoff" Stabilization decreases gradually as stroke movement speed increases

7)Misc: Debug playback and scrubbing in layer isolation mode. https://bugs.kde.org/show_bug.cgi?id=394199

8)Misc: Onion Skins: Reference Frames / "Tap Wari" https://bugs.kde.org/show_bug.cgi?id=395928 M148

These are my top picks so far, there are more things that are important to me, but i limited myself

I did however remember another usability improvement

-Convert Selected Frames to layers
-Convert Selected layers to animation layer

->this would save a lot of time when you need to import either and then for whatever reason you need to change it

And I also rememberred another feature I severely wanted for ages now

Easier Animated Brushes
In my opinion because we have Animation Layers it should be trivial to transform an Animation Layer into an animated brush .

Select range of frames -> RMB -> make anim brush ->dialog should popup and handle settings like loop/random/reverse and save it as a brush tip

And if you make a selection on the canvas only use contents of the selection for all the selected frames (if possible)

This would probably be in my top 5 features if this is accepted

A suggestion from Ahmet T:

#1 I know there is a colorful marking feature for frames in timeline. I wish there was a shortcut to mark these frames in red. For example i would mark 5. And 10. Frames in red, it would be very nice to be able to make a shortcut that help me jump 5 from 10.

Generalized, this should probably be a couple of new actions for selecting the previous/next frame of the same color as the currently selected frame.
This would allow users to logically organize their animations into any number of colors and skip between them however they'd like.

#2 My second suggestion is about a flip button. For instance, this button could play the frames that i chose in slow motion. Maybe, by using shortcut it can be played forward and backward. maybe it can be more comfortable for animators. for example i use 'Z' key to play animation real time(24 fps). i want to to quickly preview a short span of animation starting a few frames before the current frame and ending a few frames after the current frame, at a customizable frame rate.

Personally I'm not sure about creating a button for this, but maybe it furthers the argument that playback speed should be made more accessible instead of being hidden in a menu widget.

If have downloaded the latest version of Krita (4.3)
Much things have been fixed, and I'm learning every day new ways to do stuff within this nice drawing app.
I am writing a small python script that will render a sequence of the file that I am saving. It is a python script which runs outside krita.
It is nice that you can export a image seqeunce from the command line. The only option I am missing is a switch for the start and a switch for the end frame. With the script I am writing I am going to try to alter the maindoc.xml before rendering/exporting the seqeunce.
One thing I noticed is that the framerate is an integer based value. In europe we are used to work with 25 fps for television. And if we want to make our animation on doubles, the frame rate is 12.5 fps. Is it possible to change the framerate to a float value, so we can have a frame rate of 12.5. Or is this something I have overlooked and is already implemented.

Regards, and keep up the good work!

In T12769#234070, @hurgar wrote:

If have downloaded the latest version of Krita (4.3)
Much things have been fixed, and I'm learning every day new ways to do stuff within this nice drawing app.

Good to hear, @hurgar. You might even want to try out one of the unstable "Krita Next" nightly builds, when you get the chance.
We'd love to hear what you think about some of the other changes.

One thing I noticed is that the framerate is an integer based value. In europe we are used to work with 25 fps for television. And if we want to make our animation on doubles, the frame rate is 12.5 fps. Is it possible to change the framerate to a float value, so we can have a frame rate of 12.5. Or is this something I have overlooked and is already implemented.

Actually I'm not quite sure I understand.. Can't you just set the frame rate to 25fps and skip every other frame?

At any rate, we can look into adding support for non-integer framerates if needed.

Regards, and keep up the good work!

Thanks! We'll do our best. :]

Is there any news on cycles?

also something that may have been forgotten is to have folders have keyframes too.

And by this i mean that folders if you move the folder that you make a keyframe that remembers the location or transform.

This way for example you can make a bird flying cycle and then move that bird without needing to redraw or copy paste everything.

Another way to do this would be with transform masks being able to have keyframes.

@Bollebib Sorry for the delayed response.

About cycles:

We have a WIP MR which will add support for Clone Frames and will be merged into master and available in nightly builds as soon as September.
It is built on top of a large refactor of some parts of the animation backend and we have to wait until the end of the Google Summer of Code to merge that, so we don't get in the way of the students.
https://invent.kde.org/graphics/krita/-/merge_requests/469

This isn't a full system of defining cycles yet, but it will allow you to clone keyframes so that they can be reused on multiple frames and edited at the same time. (They are effectively the same frame in memory.)
Hopefully this feature will be a good start though, as it will allow animators to create their own 'cycles' using clones for now.
(It will also help us iron out any potential issues with instancing frames before we delve into the more complicated backend/UI tasks of cycle objects.)

About animated transforms and transform masks:

This is something that we're stilling planning on doing, and I hope that some of our background work will make this easier to add in the future.
But there's still quite a bit of work to be done before this is ready, so I don't have an ETA for this feature just yet... :(

IRC note about groups.

Bollebib
hey ^^
i just encountered something that i probably forgot to say as feedback for animation that is kind of important
we would need to be able to move groups and create frames on groups
basicly if a group has an animation layer, the frames in that group should be visible on the group timeline
and if you transform a group, than each layer IN that group should create a frame
oh wait that does happen, ingore that last part
emmetpdx
Bollebib: So, you want to be able to see the frames of all the children layers in a group track?
Bollebib
emmetpdx: yes
this would also help with the fact that if you move a group and then you try to go to the next possible frame nothing happens cause you're not on an animation layer
it is frustrating