Future of the animation feature

Timothée Giet animtim at gmail.com
Sat Dec 20 20:09:57 UTC 2014


Le 20/12/2014 21:09, Boudewijn Rempt a écrit :
> On Saturday 20 December 2014 Dec 20:14:00 Jouni Pentikäinen wrote:
>
>> 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.
> Ah, no. I don't want to show all layers that are used in all frames in krita's layerstack. That's Photoshop's approach, where you have all possible 'cells' as a layer in the image's layerstack and then for every frame have to hide or show them to get the configuration you want.
>
> That's no good. The power of krita is in editing and rendering an image that consists of layers.
>
>> 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.
> Well, the terminology is obscure here. What is a cell, a frame, a layer?
>
> * A krita node is an instance of a layer or mask object.
>
> * A cell has a Krita node (layer or mask) which can be shown in any number of frames. Any number of cells can refer to same node.
>
> * A layer is a row where for each frame you can put a cell, or not. A cell points to a Krita node
>
> * A frame is a column where for each layer, there can be a cell in any of the rows of that column, or not.
>
> * Any layer/frame coordinate can empty or filled with a cell, and if filled, visible or hidden.
>
> The structure of the column of layers is defined in Krita's layerbox, i.e., as KisImage.
>
> Moving between frames in a clip is like moving between 'virtual' KisImages.
>
> I think that this allows for maximum flexibility, and will also make caching, onion skinning and rendering easy.
>
> But basically, I don't want to limit thinking by assuming a single KisImage needs to contain everything.
>
>
That is a good terminology explanation, I think.


More information about the kimageshop mailing list