Gizmos do not appear when editing normals via the rotate or point to target functions #65147

New Issue

Hidalgo Lakhdi · 2019-05-26T15:08:17+02:00

Hidalgo Lakhdi commented

2019-05-26 15:08:17 +02:00

System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: Intel(R) HD Graphics 620 Intel 4.5.0 - Build 24.20.100.6292

Blender Version
Broken: version: 2.80 (sub 72), branch: master, commit date: 2019-05-25 23:18, hash: f18373a9ab
Worked: (optional)

Short description of error
When editing normals using the "rotate" or "point to target" options in the Alt-N normal menu, no gizmo appears to control these functions using the mouse. This behavior isn't consistent with the behavior shown in this video .

Exact steps for others to reproduce the error

Open new "General" file

(Optional: Enable normal visualization gizmos)

Select cube and go into edit mode

Choose the "rotate" or "look at target" options

Gizmo for mouse does not appear

**System Information** Operating system: Windows-10-10.0.17763 64 Bits Graphics card: Intel(R) HD Graphics 620 Intel 4.5.0 - Build 24.20.100.6292 **Blender Version** Broken: version: 2.80 (sub 72), branch: master, commit date: 2019-05-25 23:18, hash: `f18373a9ab` Worked: (optional) **Short description of error** When editing normals using the "rotate" or "point to target" options in the Alt-N normal menu, no gizmo appears to control these functions using the mouse. This behavior isn't consistent with the behavior [shown in this video ](https://youtu.be/Rqsgrg_SVME?t=123). **Exact steps for others to reproduce the error** # Open new "General" file # (Optional: Enable normal visualization gizmos) # Select cube and go into edit mode # Select a face and open the Alt-N normal editing menu # Choose the "rotate" or "look at target" options - Gizmo for mouse does not appear

Hidalgo Lakhdi commented

2019-05-26 15:08:17 +02:00

Added subscriber: @frarf

William Reynish commented

2019-05-26 21:15:42 +02:00

Added subscribers: @howardt, @WilliamReynish

Howard Trickey was assigned by William Reynish

2019-05-26 21:15:42 +02:00

William Reynish commented

2019-05-26 21:15:42 +02:00

I can confirm this. What you mean by 'gizmo' isn't what we internally call a gizmo though. It's the cursor + connection line that is missing in this case.

@howardt Perhaps you could take a look?

I can confirm this. What you mean by 'gizmo' isn't what we internally call a gizmo though. It's the cursor + connection line that is missing in this case. @howardt Perhaps you could take a look?

Hidalgo Lakhdi commented

2019-05-27 15:16:38 +02:00

Oh, sorry. I'm not familiar with all the Blender lingo quite yet.
Thank you for forwarding this! I really appreciate it, normal tools are important.

Oh, sorry. I'm not familiar with all the Blender lingo quite yet. Thank you for forwarding this! I really appreciate it, normal tools are important.

Howard Trickey commented

2019-05-29 13:33:21 +02:00

Yes, it is not just that the UI doesn't show the connection lines, but that in fact the Rotate option of the menu doesn't work at all -- I guess the modal operation finishes immediately. As a workaround until I fix this, you can use the r shortcut followed by n to rotate the selected normal(s). Or it also works to do an F3 search for Rotate Normals and select that.
But i will work on trying to get the menu method to work. Thanks for the report.

Yes, it is not just that the UI doesn't show the connection lines, but that in fact the Rotate option of the menu doesn't work at all -- I guess the modal operation finishes immediately. As a workaround until I fix this, you can use the r shortcut followed by n to rotate the selected normal(s). Or it also works to do an F3 search for Rotate Normals and select that. But i will work on trying to get the menu method to work. Thanks for the report.

Hidalgo Lakhdi commented

2019-05-30 14:24:08 +02:00

Thank you! Yes, that works, that's more than enough for me.
Anytime, glad to help.

Thank you! Yes, that works, that's more than enough for me. Anytime, glad to help.

Howard Trickey commented

2019-05-30 18:47:39 +02:00

Added subscriber: @ideasman42

Howard Trickey commented

2019-05-30 18:58:18 +02:00

Campbell: When the "Rotate Normals" menu is selected from the Mesh > Normals submenu, it gets a context that has INVOKE in it whereas if it is selected via the same submenu when it pops up after hitting Alt-n (to which it is mapped), it gets a context that has EXEC in it.
.
This means that the operator is INVOKED when you select it from the header menu, but EXECED when you select it from the shortcutted popup menu. Is this intended? It means that the modal operation doesn't happen when selected from the Alt-n menu, rendering this particular operation useless.

How should we fix this?

Campbell: When the "Rotate Normals" menu is selected from the Mesh > Normals submenu, it gets a context that has INVOKE in it whereas if it is selected via the same submenu when it pops up after hitting Alt-n (to which it is mapped), it gets a context that has EXEC in it. . This means that the operator is INVOKED when you select it from the header menu, but EXECED when you select it from the shortcutted popup menu. Is this intended? It means that the modal operation doesn't happen when selected from the Alt-n menu, rendering this particular operation useless. How should we fix this?

William Reynish commented

2019-05-30 19:29:33 +02:00

@howardt isn’t it just a matter of setting the operator context to invoke?

Howard Trickey commented

2019-05-30 20:05:31 +02:00

Is that something settable in the keymap editor? Haven't looked, but will. About to get on a plane for a vacation...

blender-admin commented

2019-05-31 08:24:58 +02:00

This issue was referenced by b4071c56ce

This issue was referenced by b4071c56cedf4c55d1fb3e6847e63bdbd172f1dd

Campbell Barton commented

2019-05-31 08:26:06 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2019-05-31 08:26:06 +02:00

Howard Trickey commented

2019-06-01 21:24:41 +02:00

Changed status from 'Resolved' to: 'Open'

Howard Trickey reopened this issue

2019-06-01 21:24:41 +02:00

Howard Trickey commented

2019-06-01 21:24:41 +02:00

Campbell, your fix of putting

 layout.operator_context = ‘INVOKE_DEFAULT'

in front of the rotate normals menu entry appears not to work (or at least, work well) when the menu is entered via the Mesh > Normals > Rotate Normals entry.
What happens is that the dotted line that joins the mouse to the cursor is not shown, and the mouse movement causes very limited change in the rotation angle, such that it is hard to even notice that the normals are being rotated.

I tried to debug, and found that with your change, the code invoked that way now gets to wm_operator_call_internal() with a context argument of 0 (INVOKE_DEFAULT) rather than 1 (WM_OP_INVOKE_REGION_WIN) which it did when invoked that way without the assignment of INVOKE_DEFAULT in the menu definition code. This has the effect, in that function, of not doing all of the code that figures out which region to change to with CTX_wm_region_set. So the region with your fix is header instead of the main window (at least I think that from where ymin and ymax are in the region rectangle). This is likely why the mouse-drawing and measurement related code later in the normal rotation transform code behaves strangely.

Sorry to throw this back to you, but I don't know how to fix. I tried setting layout.context to WM_OP_INVOKE_REGION in the menu code, but that didn't work at all -- the menus stopped getting drawn at the rotate-normals entry.

Campbell, your fix of putting ``` layout.operator_context = ‘INVOKE_DEFAULT' ``` in front of the rotate normals menu entry appears not to work (or at least, work well) when the menu is entered via the Mesh > Normals > Rotate Normals entry. What happens is that the dotted line that joins the mouse to the cursor is not shown, and the mouse movement causes very limited change in the rotation angle, such that it is hard to even notice that the normals are being rotated. I tried to debug, and found that with your change, the code invoked that way now gets to wm_operator_call_internal() with a context argument of 0 (INVOKE_DEFAULT) rather than 1 (WM_OP_INVOKE_REGION_WIN) which it did when invoked that way without the assignment of INVOKE_DEFAULT in the menu definition code. This has the effect, in that function, of not doing all of the code that figures out which region to change to with CTX_wm_region_set. So the region with your fix is header instead of the main window (at least I think that from where ymin and ymax are in the region rectangle). This is likely why the mouse-drawing and measurement related code later in the normal rotation transform code behaves strangely. Sorry to throw this back to you, but I don't know how to fix. I tried setting layout.context to WM_OP_INVOKE_REGION in the menu code, but that didn't work at all -- the menus stopped getting drawn at the rotate-normals entry.

Howard Trickey was unassigned by Campbell Barton

2019-06-11 12:58:05 +02:00

Campbell Barton self-assigned this 2019-06-11 12:58:05 +02:00

Campbell Barton commented

2019-07-01 09:13:32 +02:00

Interesting, accessing any transform from the header has this problem, it applies to 2.7x too.

While it should be fixed it's not a new problem.

Looked into this, the screens active region needs to be changed from the header to the window region, or the cursor could use a region other than the screens active region.

Interesting, accessing *any* transform from the header has this problem, it applies to 2.7x too. While it should be fixed it's not a new problem. ---- Looked into this, the screens active region needs to be changed from the header to the window region, or the cursor could use a region other than the screens active region.

Philipp Oeser commented

2019-09-05 18:35:15 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-09-05 18:35:15 +02:00

regarding the usage from the header, there was eae9b86297

regarding the usage from the header, there was eae9b86297

Campbell Barton was unassigned by Dalai Felinto

2019-12-23 16:34:16 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Gizmos do not appear when editing normals via the rotate or point to target functions #65147

Open new "General" file

(Optional: Enable normal visualization gizmos)

Select cube and go into edit mode

Select a face and open the Alt-N normal editing menu

Choose the "rotate" or "look at target" options