[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Future of the animation feature
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2014-12-20 20:09:26
Message-ID: 11652249.uE67ENTRZh () linux-zth1 ! site
[Download RAW message or body]

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.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]