Summary: | Animation curves - Transform Mask - Rotation not intuitive | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | grum999 |
Component: | Animation | Assignee: | Eoin O'Neill <eoinoneill1991> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | eoinoneill1991, tamtamy.tymona |
Priority: | NOR | Keywords: | release_blocker |
Version: | nightly build (please specify the git hash!) | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/krita/commit/a4e31a2b3048cc5328b7616fd4182f86358fa4d4 | Version Fixed In: | |
Attachments: | Pivot point regression |
Description
grum999
2021-06-09 17:33:42 UTC
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 |