Fix transform calculations for drag-moving CanvasItems in editor #82667
Conversation
|
Found a case that's still broken: |
Ah, right, I've made the movement be locked to local X/Y axes, but:
Just skewing a single item is enough to see this discrepancy in action. So what's desired here?:thinking: Keeping the gizmo axes perpendicular as is and just changing the Y drag to match the gizmo direction? |
Yes, gizmos should always display in the same way. If they were transformed it would appear bugged. |
kleonc
force-pushed
the
canvas-item-editor-drag-moving-transforms-fix
branch
from
7c1fad1
to
6f941cd
Compare
| Transform2D parent_xform = selected->get_global_transform_with_canvas() * selected->get_transform().affine_inverse(); | ||
| Transform2D unscaled_transform = (transform * parent_xform * selected->_edit_get_transform()).orthonormalized(); | ||
| Transform2D simple_xform = viewport->get_transform() * unscaled_transform; |
There was a problem hiding this comment.
Changed it so this transform is calculated just like in many different places in this file. The last part (viewport->get_transform() *) don't make much sense to me, something seems off. The viewport here is a Control and according to the docs in _gui_input the events should be relative to such control, so applying its own transform on top makes no sense. Maybe the docs lie, maybe here things are incorrect. For now leaving it calculated as in other places as it seems like a potential pandora box (changing it here, would require changes in 20 different places and so on). For potential another PR.
|
Thanks! |
Fixes #82643.
Lately these calculations were tweaked in #81735 but we must have tested only some simple cases. In #81735 (comment) I deduced the
drag_from/drag_toare in the parent coordinate space, but I've deduced it only based on the new code in that PR (which seemed to work). This was a wrong a conclusion. Now I've properly taken a look at a bigger chunk of code anddrag_from/drag_toseem to be in the Viewport's global canvas coordinate space (viewport space transformed by inverse of itsglobal_canvas_transform). Updated the calculations accordingly, now things seem to work just fine.(To be clear things were broken for "non-standard" transforms even before #81735.)