SUMMARY More detailed information on krita-artist.org https://krita-artists.org/t/krita-5-animation-curves-applied-to-transform-mask/24895/1#animation-curves-transform-mask-rotation-not-intuitive-13 STEPS TO REPRODUCE 1) Create a paint layer with a rectangle 2) Add a transform mask on paint layer 3) Create first keyframe at frame 0 4) Move to another frame (example, frame 15) 5) Select “Transform tool” 6) Do a counter-clockwise rotation (example -15°) OBSERVED RESULT 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 RESULT 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. SOFTWARE/OS VERSIONS Linux appimage krita-5.0.0-prealpha-dba5ce5-x86_64.appimage ADDITIONAL INFORMATION Maybe it's more an improvement than a bug, but for whom is used to work with other software where tweening is available, the way Krita manage tje rotation is not logical/intuitive Grum999
I have this on my list, but it's worth noting that we can't actually track the "direction" a user rotates and assume that's the intended rotation. The quick solution here is to rotate in the shortest possible path with the way Krita's transform system works. Shortest possible path should win by default, and users can create multiple keyframes to control that. It's worth noting that, if we were using multiple matrices to change origin and rotate (equivalent of model->view matrix) of the transform masks, it would be easier to track desired rotation angles over time.
*** Bug 438303 has been marked as a duplicate of this bug. ***
Hi Ah sorry, I didn't saw Bug 438303 I understand idea of shortest path, but in this case, what if I really want a +270° rotation and not a -90°, what happen? Currently if rotation value is set manually, Krita works in the right way: a 720° (clockwise) or -720° (counter-clockwise) is properly taken in account (2 full complete rotation applied in the right direction). On my side, the problem is more relative about how the rotation angle is defined when using mouse (or pen). For example, when rotating canvas: - clockwise rotation: rotation value is positive - counter-clockwise: rotation value is negative So when rotating with transform mask, it should be possible to determinate in which direction the user is applying the rotation, and apply a positive or negative value instead of always a positive value Grum999
There's a way to determine general directionality of course. The problem is that we also need to address floating point inaccuracies at high values. Due to this, we will need some kind of rotation normalization -- but we'll probably just handle this as we get to it though. I'll bring this up with dmitryK next week with a pull request that removes the rotation normalization.
"The problem is that we also need to address floating point inaccuracies at high values. Due to this, we will need some kind of rotation normalization" You lost me there ^_^' I don't know how Krita is internally working so, I just let you do what you think to be the best :) Grum999
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/902
Git commit d525190d4e8799bd61d4f61c57cfea6021e01baf by Eoin O'Neill. Committed on 07/07/2021 at 20:38. Pushed by eoinoneill into branch 'master'. Free Transform: Support negative rotation, track rotation direction for animation intent. M +2 -3 plugins/tools/tool_transform2/kis_free_transform_strategy.cpp https://invent.kde.org/graphics/krita/commit/d525190d4e8799bd61d4f61c57cfea6021e01baf
Hi I reopen the bug. It's working, but now the pivot point of transform mask is positionned to origin of document and not to transform mask center anymore... Video example from krita-5.0.0-prealpha-ebe5933-x86_64.appimage 1) Create transform mas; keep it as selected layer 2) In animation curves, add a first keyframe 3) In animation curves, add a second keyframe 4) Select transform tool and click on canvas: - transform mask limits+grip are ok - transform mask pivot point is not on the right place Doing the same action on previous build krita-5.0.0-prealpha-453b8c7-x86_64.appimage, pivot point is centered on transform mask bounds So for me it could considered as a regression; by default pivot point should be centered Grum999
Created attachment 139975 [details] Pivot point regression
Grumm, Ah regressions, the curse of the bug continues. That's ok, I think I can isolate a cause, though it's a bit strange since it doesn't seem to happen consistently...
Git commit a4e31a2b3048cc5328b7616fd4182f86358fa4d4 by Eoin O'Neill. Committed on 14/07/2021 at 03:56. Pushed by eoinoneill into branch 'master'. Fixed regression caused by threading fix for animated transforms. Transform should now properly be initialized to the center of device when creating an AnimatedTransformMaskParams instance. M +27 -44 plugins/tools/tool_transform2/kis_animated_transform_parameters.cpp https://invent.kde.org/graphics/krita/commit/a4e31a2b3048cc5328b7616fd4182f86358fa4d4
I found the issue. The reason why it was inconsistent had to do with the way transform masks work where they start "uninitialized" until the first attempt to transform. Basically, since I would often transform the object first before converting it to an animated transform, I would only rarely run into this offset bug in my testing. Thanks again grum999 for all the testing. If you have any other issues please feel free to reopen. I don't know if you have assignment features, but assign them to me as well. Cheers, Eoin.
Hi I can confirm that on last tested appimage (krita-5.0.0-prealpha-627782b-x86_64.appimage) the problem is fixed :) Grum999