UV Transform Tool - broken handles #83310

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1650 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71

Blender Version
Broken: version: 2.91.0, branch: master, commit date: 2020-11-25 08:34, hash: 0f45cab862
Broken: also 2.83 and 2.90

Short description of error
When move Transform Tool handles "Rotate" and "Resize" they works with bugs

Exact steps for others to reproduce the error

"Rotate" handle also rotate island when move mouse up and down.
UVTransform_Tool_Rotate.mp4
"Resize" handles do not respect aspect ratio visually when resize, but do when you finish operation.
UVTransform_Tool_Resize.mp4
Works correctly only resize by sides
UVTransform_Tool_Resize_Sides.mp4

Added subscriber: @APEC

Added subscriber: @mano-wii

Changed status from 'Needs Triage' to: 'Confirmed'

Thanks for the report, I can confirm.

Added subscriber: @lichtwerk

Scale Cage in 3D does the same thing btw. [in regards to corner resizing]

Added subscriber: @ideasman42

Looked into this a bit, but afaics, this is a design limitation?

In case an operator is tied to the gizmo, there is some stuff that gets set up for the operator prior to going modal.
In the case of cage corner resizing for example the center_override property of the resize operator gets set according to which corner gets grabbed etc.

But once this is done, I dont see an easy way to inject scale values into the operator properties?
There is also this comment:

/* if gizmo evokes an operator we cannot use it for property manipulation */

Of course, there is still stuff from the gizmo that runs in modal, in this case gizmo_cage2d_modal.
This makes sure the gizmo is drawn with the correct scaling and this all works fine.
But this is called after the operator modal has already done its thing, specifically in wm_gizmomaps_handled_modal_update

I have tried injecting the scale into the resize operators value property like so (but again, the resize operator has already done its transform_modal):
P1922: T83310_snippet



diff --git a/source/blender/editors/gizmo_library/gizmo_types/cage2d_gizmo.c b/source/blender/editors/gizmo_library/gizmo_types/cage2d_gizmo.c
index be5f488d759..8b32f8261ec 100644
--- a/source/blender/editors/gizmo_library/gizmo_types/cage2d_gizmo.c
+++ b/source/blender/editors/gizmo_library/gizmo_types/cage2d_gizmo.c
@@ -1094,6 +1094,10 @@ static int gizmo_cage2d_modal(bContext *C,
     transform_pivot_set_m4(matrix_scale,
                            (const float- [x]){pivot- [x] * dims- [x], pivot- [x] * dims- [x], 0.0f});
     mul_m4_m4m4(gz->matrix_offset, data->orig_matrix_offset, matrix_scale);
+
+    PropertyRNA *prop_value = RNA_struct_find_property(&gz->op_data->ptr, "value");
+    RNA_property_float_set_array(
+        &gz->op_data->ptr, prop_value, (float- [x]){scale- [x], scale- [x], scale[1]});
   }
 
   if (gz_prop->type != NULL) {

The place where manipulating operator properties actually works is gizmo2d_xform_refresh
That already does WM_gizmo_operator_get / RNA_property_float_set_array on the center_override (see above)
Manipulating values here actually also works for said value, but only updates when the operator finishes.

Not sure if there is anything that could be done with gizmos target_properties, but again, the comment about gizmos tied to operators makes me think this is a dead end as well.

Soo: think I have to step down here, for me this looks like a Design Issue and not a bug [it sure works against user expectations], probably @ideasman42 would know best...

Looked into this a bit, but afaics, this is a design limitation? In case an operator is tied to the gizmo, there is some stuff that gets set up for the operator prior to going modal. In the case of cage corner resizing for example the `center_override` property of the resize operator gets set according to which corner gets grabbed etc. But once this is done, I dont see an easy way to inject scale values into the operator properties? There is also this comment: > /* if gizmo evokes an operator we cannot use it for property manipulation */ Of course, there is still stuff from the gizmo that runs in modal, in this case `gizmo_cage2d_modal`. This makes sure the gizmo is drawn with the correct scaling and this all works fine. But this is called after the operator modal has already done its thing, specifically in `wm_gizmomaps_handled_modal_update` I have tried injecting the scale into the resize operators `value` property like so (but again, the resize operator has already done its `transform_modal`): [P1922: T83310_snippet](https://archive.blender.org/developer/P1922.txt) ``` diff --git a/source/blender/editors/gizmo_library/gizmo_types/cage2d_gizmo.c b/source/blender/editors/gizmo_library/gizmo_types/cage2d_gizmo.c index be5f488d759..8b32f8261ec 100644 --- a/source/blender/editors/gizmo_library/gizmo_types/cage2d_gizmo.c +++ b/source/blender/editors/gizmo_library/gizmo_types/cage2d_gizmo.c @@ -1094,6 +1094,10 @@ static int gizmo_cage2d_modal(bContext *C, transform_pivot_set_m4(matrix_scale, (const float- [x]){pivot- [x] * dims- [x], pivot- [x] * dims- [x], 0.0f}); mul_m4_m4m4(gz->matrix_offset, data->orig_matrix_offset, matrix_scale); + + PropertyRNA *prop_value = RNA_struct_find_property(&gz->op_data->ptr, "value"); + RNA_property_float_set_array( + &gz->op_data->ptr, prop_value, (float- [x]){scale- [x], scale- [x], scale[1]}); } if (gz_prop->type != NULL) { ``` The place where manipulating operator properties actually works is `gizmo2d_xform_refresh` That already does `WM_gizmo_operator_get` / `RNA_property_float_set_array` on the `center_override` (see above) Manipulating values here actually also works for said `value`, but only updates when the operator finishes. Not sure if there is anything that could be done with gizmos target_properties, but again, the comment about gizmos tied to operators makes me think this is a dead end as well. Soo: think I have to step down here, for me this looks like a Design Issue and not a bug [it sure works against user expectations], probably @ideasman42 would know best...

I've looked at problems like this before.

From my point of view, the problem is that the basic idea of gizmos is that they inform the values to the operator to perform and not the other way around.
A possible solution would be to update the "target_property" "matrix" of the gizmo, since it is used for reading and writing (see WM_gizmo_target_property_def_func).
Another possible solution would be to prevent the gizmo from performing the modal operation and just update the matrices in the operator itself.
Another solution (which is used in the rotate operator of the view3d), is to hide the gizmo and reuse its drawing functions.

(There are also other options like overriding the modal callback of gizmo with WM_gizmo_set_fn_custom_modal and redoing a modal just for the transform operator).

But none of these options seem to be ideal as the intention is only to update the drawing, and the ideal design should make this possible in both C and Python.

Added subscriber: @Chris_Blackbourn

Testing in commit ccb4e29873 from 2022-05-10

The behavior in all three videos appear to be working correctly now, with the only difference being the cage disappears during the interaction.

Is this task complete, or is there more here that needs to be done?

Changed status from 'Confirmed' to: 'Resolved'

Agree this task can be closed. Any further improvements the could be created as more specific TODO's.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UV Transform Tool - broken handles #83310