Future of the animation feature

[Timothée Giet]

Le 21/12/2014 15:27, Boudewijn Rempt a écrit :
> On Sun, 21 Dec 2014, Sven Langkamp wrote:
>
>> On 12/21/14, Boudewijn Rempt <boud at valdyas.org> wrote:
>>> On Saturday 20 December 2014 Dec 21:09:57 Timothée Giet wrote:
>>>
>>>> That is a good terminology explanation, I think.
>>>
>>> Okay, keeping this terminology, I think that it boils down to what 
>>> Jouni
>>> already said: what's primary, the row, or the column -- the layer or 
>>> the
>>> frame.
>>>
>>> So, we either create the concept of time, and place KisImage inside 
>>> it, or
>>> take KisImage, and place the concept of time in KisImage. My 
>>> thoughts were
>>> all going in the first direction, but under the shower I started 
>>> thinking of
>>> the implications of the second direction.
>>
>> I'm clearly in favor of putting the time into the image. It's better
>> to combine static with animated objects e.g. a static background with
>> several animated layers in front of it.
>>
>> Beside that I think it would offer better performance. If you insert a
>> new layer the already composited parts stay the same.
>>
>>> I'm not sure what will be easier, technically, when it comes to 
>>> things like
>>> rendering the layerstack, preparing cached frames, swapping out 
>>> KisNodes,
>>> but here are some points:
>>
>> I think it's easier to implement. If you e.g. want to insert a new
>> layer into the image it's much simpler. If you have time outside of
>> the KisImage you have to sync all the images.
>
> But don't think in terms of 'the image' -- if the timeline is outside 
> KisImage, we'd generate a KisImage for every frame, with references to 
> the nodes used in the timeline.
>
>>
>>> * If we put the idea of time in KisImage, we shouldn't create special
>>> layers.
>>
>> Agreed.
>>
>>> * We should instead make time a first-class property of KisImage, 
>>> with a
>>> 'still' image having just one frame.
>>
>> Yes, KisImage should have a current frame which is the state that you
>> are working on. Changing that would move any layer with an animation
>> to the specified frame.
>>
>>> * All layers (including group layers) should get the idea of time
>>
>> Group layers should be timeless objects, so only the layers inside
>> them are animated. If the group layer had time, it would be possible
>> that the layers stack changes during the animation which I think is a
>> nightmare to manage.
>
>
> Well, no... Because grouplayers have visibility, and that needs to be 
> animatable.
>
>>
>> So layer may or may not have animation support e.g. generate layer,
>> file layer or vector layer. These might need a totally different type
>> of animation.
>
> Yes -- well, every layer has the basic animation of visibility, 
> position, opacity, blending mode.
>
>>
>>> * Time should apply not just to paint devices, but also to 
>>> properties like
>>> visibility, and for filter layers and masks, to the filter config.
>>
>> I think things like visibility should be global e.g. the user might
>> want to watch the animation with one element hidden so he just hides
>> that layer.
>
> Yes, and no -- the user for sure would like to be able to hide all of 
> a layer in one go, but it's also necessary to toggle visibility, 
> opacity etc. on a frame-by=frame base.
>

About opacity, what an animator will need is not directly frame/frame 
values, but rather to set keyframe values and get interpolation between 
keys. This could be better handled using a curve in the timeline (we 
could have foldable settings curves for each layers in the timeline..).

Visibility could be animated switching opacity 0-100%.

This way we could keep visibility button to hide a layer, and maybe keep 
the opacity animation relative to layer opacity slider value.




>> Not sure how we model the changes of the properties.
>
> BOudewijn
>
>
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20141221/215addb3/attachment.html>