Krita 5 - Animation curves applied to transform mask

Develop Artists Feedback & Testing
1

Hi

On my last animation, I had many difficulties to work with Krita due to bugs…

NOTE: Before opening a bugzilla, I’ll try to describe here what happen in which situation (before bugzilla is just hell to format properly explanation and embed screenshot and videos)

In a second time, I’ll create a bugzilla with minimal explanation and a link here

I’m aware that this is not ideal to have things explained in differents places but sincerely, current bugzilla version is from an another age and it doesn’t incite to take time to provide precise descriptions

Animation curves - Rotation with Transform Mask - Glitches

STEPS TO REPRODUCE

  • Create a paint layer with a rectangle
  • Add a transform mask on paint layer
  • Apply a rotation with pivot point not positioned in center of transform mask
    image
    image821×387 34.1 KB
  • Create some keyframes in animation curves

OBSERVED RESULTS

In the following video, scene is already built; I just:

  1. Navigate to next frame
  2. Play animation (so frames are rendered in cache)

Render for rotation is very bad…

Note: I suspect the problem is relative to pivot point and rotation, not specifically to animation, but in an animation it’s a really visible bug

EXPECTED RESULTS

Render properly applied on all frames, whatever the position of pivot point

Animation curves - Transform Mask - New keyframe between 2 keyframes + ESCAPE

For this one, I’m not sure about what is happening, but it’s really disturbing.

STEPS TO REPRODUCE

  • Create a paint layer with a rectangle
  • Add a transform mask on paint layer
  • Create some keyframes in animation curves
  • Start to navigate between keyframe
  • Select “Transform tool”
  • Click on layer

OBSERVED RESULTS

(A) A new keyframe is created, but it’s sometime created with wrong values.

image
image1389×893 147 KB

Note: it seems the strange curves are related to the pivot point; new interpolated values seems to be calculated as if pivot point was centered

So, the reflex is to press Escape
==> Result is worst

image
image1652×1332 193 KB

(B) I suspect that, in a non animated transformation mask the escape key reset all transformations.

image
image1278×1287 157 KB

So now, I don’t want this keyframes.
The reflex is not to delete ALL key point for curves, but it’s to do CTRL+Z
(C) The cancel action doesn’t work: it will undo what has been made before this action. New keyframe stay in place

Complete video

EXPECTED RESULTS

(A) When transform tool is selected, if a new keyframe is created, to should always be created with the right interpolation values
(B) When Escape key is pressed in an animation curve, I think reset should reset to current interpolation values
(C) Undo action when a keyframe has been created in this workflow is to undo keyframe creation

Animation curves - Transform Mask - New keyframe

STEPS TO REPRODUCE

  • Create a paint layer with a rectangle
  • Add a transform mask on paint layer
  • Create first keyframe at frame 0
  • Move to another frame (example, frame 15)
  • Select “Transform tool”
  • Click on layer

OBSERVED RESULTS

For the second keyframe, created automatically when transform tool is applied to layer, value are incorrect:

  • No transformation is applied
  • Curves defines a transformation

If we move to another frame, the right values are applied to curves

EXPECTED RESULTS

When a new keyframe is created without transformation, curves should represent the right values.

Animation curves - Transform Mask - Rotation not intuitive

STEPS TO REPRODUCE

  • Create a paint layer with a rectangle
  • Add a transform mask on paint layer
  • Create first keyframe at frame 0
  • Move to another frame (example, frame 15)
  • Select “Transform tool”
  • Do a counter-clockwise rotation (-15°)

OBSERVED RESULTS

By default, a counter clockwise rotation of 15° in Krita is equivalent to a 345° clockwise rotation.

Normally it’s not a problem.
But when tweening, result in not intuitive: the rotation is really a 345° clockwise rotation.

We have to change value to -15°

EXPECTED RESULTS

When working on an animation:

  • If user is doing a clockwise rotation to set angle, animation must be clockwise
  • If user is doing a counter-clockwise rotation to set angle, animation must be counter-clockwise

So finally:

  • If user is doing a clockwise rotation, rotation value should be positive
  • If user is doing a counter-clockwise rotation, rotation value should be negative

Currently that’s really boring to have to calculate currentRotation - 360 each time we need to set a counter-clockwise rotation.
It needs to be natural to user.

NOTE:

  • Currently tested on krita-5.0.0-prealpha-dba5ce5-x86_64.appimage
  • I didn’t finished, I have other problems/bugs to describe, but currently it’s 0.30am here and I have to go to bed, tomorrow I have to go to the office :cry:
  • During my tests to write this, I don’t know what I did with transformation mask but Krita completely freezed my computer; even MAJ & NUMERIC keys on keyboard were stuck… I had to made a hard reboot of computer… I’ll try to check if I’m able to reproduce this or not…

Grum999

4 Likes
2

Note that if you make a bug report, we can mark it as “release_blocker” and then 5.0 won’t be released before it gets fixed, while the post on the forum can get lost easily :wink:

3

Hey @Grum999, thanks for testing and sorry you ran into some frustrating bugs…

The number of people currently testing these features are really low, so it’s really useful to have you trying them out. Sometimes I feel like I’m the only one who sometimes animates with Krita 5, and I don’t do it very often myself. :slight_smile:

I can confirm all of these, and you’re right about them being problems. I’m sure more testing will highlight more problems over time too.

Could you please take some time to open a separate bug report for each of these issues on https://bugs.kde.org/?

I know bugzilla is really old school and KA can be great for community discussions and sharing examples, but it’s important that we get bugs like this into the system (and, like @tiar said, labelled as release blockers) so that we can make sure that they aren’t forgotten.

Thanks!

4

It’s not just the rotation transform with the fixed pivot point for all frames. If you do a perspective transform then the vanishing point is in the same place for all frames.
I haven’t looked into this in any depth at all.

5

People will hate me if release is blocked with my formalized bugs :sweat_smile:

No problem, I know that we’re currenlty in pre-alpha so I’m aware that when I use it, it could be buggy.

But the tweening feature was the most wanted feature for animation part…

Reason why there’s not very much feedback on it could be:

  • Doing tests takes time
  • Formalize bugs takes time
  • Some users just wait for final release to use it
  • Some users are not aware of new feature (even with all communication made one it)
  • Some users use other software (even me… :slight_smile:)

On my side, I don’t make animation everyday: sometime I have the motivation to create an animation, but it’s harder than a non-animated drawing, and it takes so much time. That’s a chance that I was making this animation when this feature has been released, I decided to use it to test it :wink:

@tiar @emmetpdx don’t worry I’ll try to formalize bugs in bugzilla as soon as possible, I’m aware of tracking tool are better than forum to formalize bugs :slight_smile:
That’s just that for me writing formatted text with embedded screenshots makes it easier to explain things… That’s also faster to organize things in my mind and return my thoughts.

Grum999

1 Like
6

Bugs opened.

Description in bugzilla is minimal, and I provided link here for detailed explanation with screenshots and videos:

https://bugs.kde.org/show_bug.cgi?id=438340

https://bugs.kde.org/show_bug.cgi?id=438341

https://bugs.kde.org/show_bug.cgi?id=438342

https://bugs.kde.org/show_bug.cgi?id=438343

I’ll try to continue tonight to describe other encountered bugs.

Grum999

3 Likes
7

Currently not able to provide a description of problem.
From a particular document, what I have is:

  • Nothing is rendered
  • Rendering start, but it stay blocked

I’m still trying to repeat rendering to try to find what in the document (a layer, a filter, …) can be origin of the problem.

Grum999

8

I was thinking the reason of all my problems when I tried to render my animation was this bug:
https://bugs.kde.org/show_bug.cgi?id=436524

On a small animation:
If:

  • I deactivate layer style: I can execute render with all CPU/Memory
  • I reduce frame render clone limit to 1: I can render with layer style
  • I reduce allocated memory as suggested by @tiar in bug comments: I can render with layer style

In all other cases, rendering is in failure after a ‘random’ number of frames rendered…

The bug is set as “Fixed” in bugzilla.
But on my side applied fix doesn’t work: I never use ffmpeg from Krita, always generate PNG sequence files so I’m not sure that ffmpeg is origin of problem as described in comments…

Tested on last downloaded Krita (krita-5.0.0-prealpha-7ae3f95-x86_64.appimage)

@tiar @emmetpdx: what’s the best thing to do? create a new bug? reopen the bug?

Anyway, I tried to deactivate all layer styles on my animation, and it’s still not working if more than 1 CPU is used for rendering animation (and also, in this case some rendered frames have glitches)

So there’s something else with my animation that I’m currently unable to isolate when I try to create small testing animations…

I’m still trying to find the origin of problem :muscle:
But it takes time…

One thing is, I don’t know in which condition the “failed to render” message popup is displayed
It could be very interesting for everyone I think to put more information in logs and/or output console about what’s happening… (I activated the log docker with all options, but there’s nothing useful)
A `–verbose-log’ option from command line where all major action are logged (calculate projection for which layer, calculate transform mask, calculate filter, export projection, … all these things, probably could help to determinate where/when/how the problem happen)

Grum999

1 Like
9

I didn’t conclude that ffmpeg was the cause of the problem. I noted that it happened during ffmpeg rendering which caused a ‘resources limit’ (RAM) situation and that reducing the size of the image (and RAM usage) removed the problem.

Is there any possibility of a RAM or other ‘resources limit’ factor in your situation?

10

The ffmpeg remark was about following comments from @eoinoneill on bug:
https://bugs.kde.org/show_bug.cgi?id=436524#c8
https://bugs.kde.org/show_bug.cgi?id=436524#c9
:slight_smile:

I can’t tell yes or no.
On my side, the computer I use for rendering I allocate 60GB RAM for Krita + 64GB swap file size.
I think there’s enough memory available :slight_smile:

I think problem is related with multithreading:

  • Multithreading in frame rendering
  • Multithreading in projections calculation
  • Multithreading in filter/layer styles calculations
    => Krita seems lost when too much thread are running :sweat_smile:

But that’s just an assumption…

Grum999

11

Yes, Eoin’s fix did seem to assume that but my observation was resource limit related.
I can barely imagine the complex interactions going on in that situation and there may be multiple causes. Then there’s the CPU limit and the Rendering Clones limit.

You do have lots of RAM :slight_smile:

Can you make your small animation available for people to run and render to see what other observations and ideas come to mind?

12

I buy one computer every 8~10years so I anticipate a little bit :smiley:

You can download a test file here (I’ll let the file here for a while, it will be deleted in few weeks)
http://www.grum.fr/tmp/test_bugs_animation_04.kra

Basically, the file have the following layers:

image
image745×413 35 KB

  • paint layers
  • transform masks
  • filter masks
  • layer styles (here deactivated)

The animation is 600frames length.

But… I found something.

If autosave is triggered during rendering, there’s a rendering failure…
Maybe it’s the (or one) origin of my problem(s); taking care to save test document before doing render, I’m able to render it with layer styles…
I have to make more test tomorrow, it’s late now and I need to go to sleep :sleeping:

Also, I don’t know why but Krita display a lot of logs in terminal output now :star_struck:
I’ll try to render the big animation tomorrow, maybe I’ll get something

Grum999

13

That’s an interesting animation.

Autosave:
If autosave tries to run, there’s a status bar notificaton that it’s been postponed and rendering continues.
The postponement notification lasts only a couple of seconds but then repeats a further four times at intervals of a few seconds, then an autosave is performed.
That stops the rendering part way through the image sequence write-out, with a failed to render message.

If autosave is disabled, or doesn’t try to run, the rendering finishes and an .mp4 file is produced with no problems.

Terminal Output:
If run from the terminal, there are a few initial start up messages about resources problems with group layers and styles.

Log file output:
There are entries for what appear to be a random selection of .png frame output events, giving a long list of parameters for the .png writing options.

ffmpeg encoding log:
This is now in /tmp/krita and is called ffmpeg.log.
It doesn’t contain as much information as the old log_encode.log and doesn’t have a statement of success or failure near the end.
It has log statements for a small random sample of the many frames instead of all the frames.

1 Like
14

I marked all the bugs you reported as “release blockers”. Btw no one should be angry at you for reporting release blocker bugs; if anything, one can be angry at developers for writing a buggy code, but that would be bogus too, since it’s not like they do it on purpose. But thing is, in code, the earlier you spot the bug, the easier it is to fix, and it’s also better to fix it before the release than after (since then it affects regular users, both professionals using Krita in their daily job and needing a reliable tool, and beginners who might be confused what’s happening). So, your checking out and participation helps a lot. All of those bugs would be there anyway; unnoticed (or, noticed only by people who don’t know how to make bug reports, or not caring about it, or not knowing they should), they could stay there, annoying future users, until the code rots so much (or just developers leave or forget that code) that fixing them would be difficult.

For that one bug that still happens to you, reopening is very much fine in this situation, it’s what you’re supposed to do :slight_smile: Emmet assumed it’s fixed, it isn’t, you reopen the bug report and say why, and that’s how the developer knows they need to still work on it :slight_smile:

1 Like
15

Ok thanks for confirmation of problem.
I’ll will create a bug about this one.

Yes, that’s just everyone is waiting for end of august :sweat_smile:
But having stable release is more important than something that is buggy, I agree.
And as new animation features are also one of major feature improvement for Krita 5, it’s better to have something working :slight_smile:

I’ll do some additional before re-open it test because the problem I encounter maybe related to autosave.

The thing that is upset me is the animation that I can’t render.
With all the possible logs activated, there’s no info… like it seems that render never start…

Grum999

16

Concerning autosave, i finally found this:
https://bugs.kde.org/show_bug.cgi?id=382418

It’s not related to Krita 5.
I’ll complete bug description.

Grum999

17

It was marked as “resolved, not a bug” by the same person who reported it, but of course without any more details…

Though this might be related instead: 410024 – Autosave prevents saving (without any message for the user)

18

I saw :pensive:

Maybe the origin of problem is the same.
But consequences are not :slight_smile:

So, do I update the bug 382418?
Or do I add a comment to bug 410024?

The interesting thing is, I have exactly the same behavior:

And don’t know why but in some case, the render is not interrupted by autosaving, even if document is modified…

Grum999

19

I have reopened the bug 382418 – Krita froze during a save and Autosave didn't save the animation
And put a link to this topic + bug 410024 – Autosave prevents saving (without any message for the user)

Grum999

2 Likes
20

A null object (or “empty”, as is called in blender) concept may help animating complex rotations, but i think this will be not implemented.