Page MenuHome

Normals Workflow
Closed, ResolvedPublic


Recently, Blender gained some new abilities related to manipulating custom normals. However, the UI to control these leave a lot to be desired.

  • There's an almost empty Normals panel in Edit Mode Tool Properties, with very esoteric options. The contents of this are too obscure.
  • There's a sub-menu in the Mesh Edit Mode menu. It's too hard to access conveniently, and mixes basic face orientation operators with the custom normals ones
  • Enabling custom normals editing is confusing. You first have to enable Auto-Smooth manually

We want to improve this workflow and UI configuration. Here's how:

  • Get rid of the Normals panel completely. The Face Strength settings are part of the operators now, and we can move the Normals Vector to the Item Transform panel in the Sidebar.
  • We want to split the Custom Normals menu from the basic Face Orientation operators
  • When using any of the custom normals operators, we can automatically add the Custom Split Normals Data. We do the same for UV editing and other related mesh data when invoking operators that require certain data layers to be enabled. This way users don't have to enable Auto-Smooth first.
  • As for the normals menu itself, we can add a shortcut to open it more easily, and/or we could make it appear at the top level if custom normals are enabled.

Additionally, in a later release we could add a Normals tool in the toolbar, with tool properties to set the sub-tool. This could make it easier to 'paint' normal directions on the mesh.



Event Timeline

William Reynish (billreynish) lowered the priority of this task from Needs Triage by Developer to Normal.May 8 2019, 8:22 PM

I agree with most of this, and have been working on it. With changes I made to the normal menu, I can now remove Face Strength from the Normals panel in Tool properties.

I initially was going down the path of putting the Normal Vector in the Item Transform panel, but it is somewhat problematic, so withdrew that idea. The reason is that it feels incompatible with the other uses of value boxes in the Item Transform panel, which as I understand it follow the paradigm of: they always reflect the value of the current selection's property (perhaps a median value), and if you change the box, it should immediately change the value of the property (in this case, the normal vector of the implicitly selected normals). One important case that this misses is the Copy/Paste scenario: you select one normal, copy it to the "Normal Vector" box (really, a scratch buffer for normals), and then select a different set of normals and paste that value back. [Actually, such a feature would be cool for other properties in the Item Transform Panel, but doesn't exist right now.) Further, the Add and Multiply functions need a separate value from the scratch buffer. I asked on forums whether people actually use those -- answer was unclear, though someone posted a video showing some weird use of this to affect NPR shading. We could consider dumping Add and Multiply, I suppose. Even Copy/Paste (requiring people to write down values on paper or somewhere and manually enter them again after changing selection). But would really like to keep at least Copy/Paste. I was pursuing idea of making a Normals tool and keeping the Scratch buffer in the tool properties (and there are a few other Normal tools that have some controller properties, not currently exposed except in Redo panel). I haven't gotten very far yet, and if Campbell wants to do this, I'd be fine with that. But also fine to try to keep on myself.

@Howard Trickey (howardt) We think we might want to change the Normal Vector number field to actually reflect what you select, just like other things in the Transform panel. That was the idea during the UI meeting we had this morning. Does that make sense?

Maybe I'm dense but I can't see why we would need a special separate value field just for copy/pasting? I mean, we could keep the copy/paste operators of course, but don't see why we need persistent fields to hold the clipboard, if you will.

@William Reynish (billreynish) Yes, I can see that (the copy/paste buffer being elsewhere and hidden).
What were the thoughts about Add/Multiply? Dump them?

@Howard Trickey (howardt) I suppose we could keep them but just let the user type in a value in the redo panel.

One question about the idea of making the normal vector in the transform tools item panel be a live reflection of the current selection: this is a not-inexpensive operation (see BM_loop_normal_editdata_array_init in bmesh_mesh.c: it allocates several #loop-length things and iterates over all the loops of the mesh). Even if we only do this if there are custom normals, is there any concern about doing this every time a selection changes? I don't think so, but wonder what others think before going down this coding path.

Suggest to first try add a tool in the tool-system for this instead of buttons in the items panel.

This is something users want to edit visually, since numbers as directions are only practical for axis-aligned values.

Having buttons that stay up to date is going to be a heavy operation (users may run into noticeable slow-downs if they happen to leave the panel visible).

Even though the tool updates will be heavy too, at least it will be limited to when the tool is in use.

Computing the median normal indeed seems expensive. It may not be too terrible in practice as custom normals are mostly used for relatively low poly meshes, and it could be in a subpanel that is collapsed by default. But still, it can be an issue.

Just removing the Add and Multiply tools may be ok. If we want to keep that functionality, we could add an "Edit Value" operator, that shows you a popup with the median normal that you can then edit. Not as elegant as a panel, but same functionality without the performance concern.

When using any of the custom normals operators, we can automatically add the Custom Split Normals Data. We do the same for UV editing and other related mesh data when invoking operators that require certain data layers to be enabled. This way users don't have to enable Auto-Smooth first.

I guess what this means is that it would enable Auto-Smooth automatically along with adding the Custom Split Normals Data? Ideally Autosmooth and Use Custom Normals should be separate settings, it's not obvious to users that they are related. Probably not a big change, but not sure there is time for it.

Custom lnors data is already automatically added by the operators when needed, afaik. So it’s only a matter of enabling autosmooth too, when needed, that should be a rather trivial change? We could also do it when adding one of the normal editing modifiers, actually…

Currently the normals menu commands all have a poll that tests for autosmooth being on. That poll should be removed and the code should just test and turn it on if not already on when those menu items are invoked. I looked once at doing this automatically in the bevel modifier when harden normals was chosen but it was annoying to do because the bevel code is all in a file that only operates on BMesh and there is no autosmooth option recorded in BMesh that could be set and propagated back to the Mesh in the modifier code. This could be corrected, of course.

Howard Trickey (howardt) closed this task as Resolved.May 20 2019, 7:56 PM

I think that this task is complete for now. We should start a new task for a real tool in the toolbar for a 2.81 or later. Since such tools are typically interactive, some possibilities would be:

  • the modal "point normals at" command (maybe with custom gizmo to help)
  • the modal "rotate normals" command (currently pretty hidden under rotate transform with n typed afterwards)
  • a new modal "set face strength" command, to let you select and set multiple faces' strengths in sequence; ideally combined with custom drawing to show which faces have which strength
  • maybe a way to display the numeric values (vector) of selected normals (like a 'measureit' for normals)?