Page MenuHome

Gizmos do not appear when editing normals via the rotate or point to target functions
Open, Confirmed, LowPublic


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

Blender Version
Broken: version: 2.80 (sub 72), branch: master, commit date: 2019-05-25 23:18, hash: rBf18373a9ab1a
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

  1. Open new "General" file
  2. (Optional: Enable normal visualization gizmos)
  3. Select cube and go into edit mode
  4. Select a face and open the Alt-N normal editing menu
  5. Choose the "rotate" or "look at target" options
  6. Gizmo for mouse does not appear

Event Timeline

William Reynish (billreynish) triaged this task as Confirmed, Medium priority.

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.

@Howard Trickey (howardt) Perhaps you could take a look?

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.

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.

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

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?

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

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

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 Barton (campbellbarton) raised the priority of this task from Confirmed, Medium to Confirmed, High.
Campbell Barton (campbellbarton) lowered the priority of this task from Confirmed, High to Confirmed, Low.EditedJul 1 2019, 9:13 AM

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.