Future of the animation feature

[Jouni Pentikäinen]

On 12/20/2014 12:57 PM, Boudewijn Rempt wrote:
 > I really want to get this structure explicit and done before working
 > on the rest -- we've had too many attempts where the animation's
 > structure was hidden in a QDomDocument or fakes by doing weird things
 > to a KisImage.

I fully agree. Currently the foremost thing with this feature is finding 
the right models to use. This is precisely why I wanted to have this 
discussion.

 > I think it's important to start with the basic way an
> animation is structured, apart from any datamodel we currently have in
> Krita.
>
> At its most basic, an animation is a sparse 2d table, with every cell
> potentiall containing an image. Every column is a frame, every row
> corresponds to something structural in the animator's mind.

This sounds like a perfectly good formal model, and a reasonable way to 
approach the problem. Personally, however, I like approach design from 
the point of view of user workflow.

> * a frame should be rendered as a Krita layerstack, i.e., when a user
> activates a frame, they should get a KisImage to work on.
>
> * every frame have the same organization of layers: so the structure of
> all the KisImages the user works on is the same, but some or even most
> layers are invisible.
>
> * but from frame to frame, a particular layer can be used or not: so
> when creating a frame, each layer only exists in potentia, and can be
> either cloned from another instance of a KisLayer in that stack position.

This is where we disagree on the design. Unless I misunderstand your 
description, this easily leads to a very long list of layers in the 
Krita layer stack. Which means either a frustrating experience with the 
stack docker or abandoning it altogether for animation.

Instead, what I would prefer is the workflow seen in most animation 
software to my knowledge. The user creates a number of layers and in 
each layer they draw a number of frames as they work trough the 
animating. Each frame may be rendered in the final animation one or 
several times, depending on its timing.

My initial proposal was a simple implementation of this approach. You 
made a good point about its limitations regarding other layer types. 
This can be remedied by changing the model slightly.

Instead of an animated paint layer, we could have layer which swaps 
between child layers. Essentially a group layer which builds its 
projection from a single layer at a time, instead of all of them. With 
the right approach to UI, most of this can be kept hidden from the user 
when not needed (by keeping the children collapsed by default, 
redirecting paint operations to the active child layer, etc.) while 
still allowing great versatility when the user wants to drill down to 
the nuts and bolts.

The timeline widget would view the animated layers and frames in a grid, 
much like before, allowing the user to easily manipulate the timing of 
frames.

> The next problem is memory and caching. Eric wants to be able to have a
> few hundred frames and a hundred layers. That means we just cannot keep
> all the image data in memory, we have to write nodes to disk and keep
> rendered frames cached. Pretty much all animation applications I've
> looked at do that in one way or another, so it's a good bet that we'll
> need to do that, too.

A few hundred frames sounds like a bare minimum for any serious 
animation work. Good caching is obviously an absolute necessity.

I would approach this on two levels. On one hand we have the frames 
themselves. The ones we are working on right now we in memory to paint 
on them. Any frames which are not "exposed" at the current time frame 
can potentially be unloaded from memory. This is easily integrated to 
the models I have proposed. It seems less trivial if the animation is 
done trough hiding/showing plain Krita layers.

Secondly, for preview of the animation we should keep a cache of final 
projections of the image for each frame. This can be a scaled down 
version, if memory requires. A smooth real-time preview seems to me a 
vital tool for quality animation.

On Sat, 20 Dec 2014, Dmitry Kazakov wrote:
> Before starting refactoring I would highly recommend to prepare at
> least a draft of UML diagrams of what you are planning to achieve.
> This way the refactoring will come faster and more successful. I
> usually create diagrams using http://creately.com They allow create
> public diagrams and edit them collaboratively.

I made a quick draft of the different approaches discussed so far:

https://creately.com/diagram/i3x32pss1

The first one is modeled from Boud's description while the other two are 
the models I have proposed. Let me know if I misunderstood the 
description somehow.

I hope we can iron out the remaining issues and find a model we can all 
agree on.