Normals Workflow #64324

Closed
opened 2019-05-08 20:22:14 +02:00 by William Reynish · 20 comments

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.

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.
Campbell Barton was assigned by William Reynish 2019-05-08 20:22:14 +02:00

Added subscribers: @WilliamReynish, @ideasman42

Added subscribers: @WilliamReynish, @ideasman42

Added subscriber: @howard

Added subscriber: @howard

Added subscriber: @howardt
Removed subscriber: @howard

Added subscriber: @howardt Removed subscriber: @howard
Member

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.

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.

@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.

@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.
Member

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

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

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

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

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.

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.

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.

Added subscribers: @mont29, @brecht

Added subscribers: @mont29, @brecht

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.

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…

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…
Member

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.

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.
Member

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Member

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)?
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)?

Added subscriber: @AlbertoVelazquez

Added subscriber: @AlbertoVelazquez

@howardt

I have seen that add/multiply or paste a custom vector was removed when is one of the main applications? why it was done? It's remove a big feature of the custom normals.

@howardt I have seen that add/multiply or paste a custom vector was removed when is one of the main applications? why it was done? It's remove a big feature of the custom normals.
Member

It would require a whole new UI to do (to have an entry box for the thing to add or multiply by or set for pasting. We couldn't figure out an good way to do that in the time before 2.80, so went with what we went with. As noted above, probably a real tool should be made with some good UI design. One can still copy a normal from somewhere else (constructed as one sees fit) and paste it. And the functionality is still available via Python.

Also, I asked in one of the user forums if people would miss the add/multiply, and almost no-one said they would. The one case someone pointed out seemed a pretty dubious toon shading application (why one would use multiplication in that case rather than just set the normals to a particular value was not at all clear).

It would require a whole new UI to do (to have an entry box for the thing to add or multiply by or set for pasting. We couldn't figure out an good way to do that in the time before 2.80, so went with what we went with. As noted above, probably a real tool should be made with some good UI design. One can still copy a normal from somewhere else (constructed as one sees fit) and paste it. And the functionality is still available via Python. Also, I asked in one of the user forums if people would miss the add/multiply, and almost no-one said they would. The one case someone pointed out seemed a pretty dubious toon shading application (why one would use multiplication in that case rather than just set the normals to a particular value was not at all clear).

I think that the impression that it is not useful is wrong. Most people didn't know the tool by that moment, but also is a important feature for a lot of situations where you need add precise normals

The ui had 2-3 proposals for that but the ui team told that they will see in a future.

I think that the impression that it is not useful is wrong. Most people didn't know the tool by that moment, but also is a important feature for a lot of situations where you need add precise normals The ui had 2-3 proposals for that but the ui team told that they will see in a future.

old proposal that solve the problem using the same idea that vertex groups weights

B801E9AE-A7B5-4DBD-B1A3-D4F681A2245B.png

old proposal that solve the problem using the same idea that vertex groups weights ![B801E9AE-A7B5-4DBD-B1A3-D4F681A2245B.png](https://archive.blender.org/developer/F8196367/B801E9AE-A7B5-4DBD-B1A3-D4F681A2245B.png)
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#64324
No description provided.