Generative modifiers (solidify, mirror) draw face normals from original face (wrong direction) #77090

Open
opened 2020-05-26 19:41:31 +02:00 by Karol Szczerba · 16 comments

System Information
@Baszczer information
Operating system: Ubuntu 20.04
Graphics card: Radeon Pro WX 7100

@Alaska information
Operating system: Linux-5.4.0-7629-generic-x86_64-with-debian-bullseye
Graphics card: GTX 1050Ti 440.82

Blender Version
Broken: 2.83 (2020-05-26 22:42) f772a4b8fa, 2.90 (2020-05-26 20:02) eb5422828a
Worked: 2.82a

Short description of error:
The viewpoint overlay for displaying faces normals in edit mode for faces that are part of a solidify modifier will always point in the direction of the face normal being solidified with Blender 2.83 and 2.90.

blend_2_82a.png
2.82a

blend_2_90.png
2.83/2.90

Exact steps for others to reproduce the error:

  1. Open Blender.
  2. Add a plane.
  3. Give the plane a solidify modifier.
  4. In the modifier panel, enable the "On cage" option for the solidify modifier.
  5. Enter edit mode on the plane.
  6. In the viewport overlays enable the "Display normals" option for faces.

#77090 - Solidify Normals.blend

In 2.82a, this will be have as expected. The normal lines will be perpendicular to the faces of the solidifies plane. In 2.83, all the normal lines align with the normal line of the face being solidified.

Video because I feel like I'm having a hard time explaining this in words:
2020-05-27 22-55-31.mp4

**System Information** @Baszczer information Operating system: Ubuntu 20.04 Graphics card: Radeon Pro WX 7100 @Alaska information Operating system: Linux-5.4.0-7629-generic-x86_64-with-debian-bullseye Graphics card: GTX 1050Ti 440.82 **Blender Version** Broken: 2.83 (2020-05-26 22:42) `f772a4b8fa`, 2.90 (2020-05-26 20:02) `eb5422828a` Worked: 2.82a **Short description of error:** The viewpoint overlay for displaying faces normals in edit mode for faces that are part of a solidify modifier will always point in the direction of the face normal being solidified with Blender 2.83 and 2.90. ![blend_2_82a.png](https://archive.blender.org/developer/F8556010/blend_2_82a.png) 2.82a ![blend_2_90.png](https://archive.blender.org/developer/F8556009/blend_2_90.png) 2.83/2.90 **Exact steps for others to reproduce the error:** 1. Open Blender. 2. Add a plane. 3. Give the plane a solidify modifier. 4. In the modifier panel, enable the "On cage" option for the solidify modifier. 5. Enter edit mode on the plane. 6. In the viewport overlays enable the "Display normals" option for faces. [#77090 - Solidify Normals.blend](https://archive.blender.org/developer/F8557638/T77090_-_Solidify_Normals.blend) In 2.82a, this will be have as expected. The normal lines will be perpendicular to the faces of the solidifies plane. In 2.83, all the normal lines align with the normal line of the face being solidified. Video because I feel like I'm having a hard time explaining this in words: [2020-05-27 22-55-31.mp4](https://archive.blender.org/developer/F8557637/2020-05-27_22-55-31.mp4)
Author

Added subscriber: @Baszczer

Added subscriber: @Baszczer

#94826 was marked as duplicate of this issue

#94826 was marked as duplicate of this issue
Member

Added subscriber: @Alaska

Added subscriber: @Alaska
Member

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

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

I will update the description of the task with details on how to reproduce the issue.

I will update the description of the task with details on how to reproduce the issue.

Added subscriber: @fclem

Added subscriber: @fclem

Ok this was a design choice to avoid this bug present in 2.82:

Capture d’écran du 2020-05-28 14-20-11.png

Put simply we use the original face normal to avoid conflicting normals for multiple faces sharing the same original face (since there will only be 1 face dot/normal displayed).

So I would reconsider this as known issue.

Ok this was a design choice to avoid this bug present in 2.82: ![Capture d’écran du 2020-05-28 14-20-11.png](https://archive.blender.org/developer/F8559903/Capture_d_écran_du_2020-05-28_14-20-11.png) Put simply we use the original face normal to avoid conflicting normals for multiple faces sharing the same original face (since there will only be 1 face dot/normal displayed). So I would reconsider this as known issue.

Added subscriber: @ideasman42

Added subscriber: @ideasman42

Changed status from 'Confirmed' to: 'Archived'

Changed status from 'Confirmed' to: 'Archived'
Campbell Barton self-assigned this 2020-06-17 05:26:00 +02:00

If current behavior is intended, there is no reason to keep this open. Closing.

If current behavior is intended, there is no reason to keep this open. Closing.
Member

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Member

Just noting that this also breaks the mirror modifier as noted in #94826 (Face Normals display as NOT mirrored when Mirror Modifier is used)

In #77090#940084, @fclem wrote:
Ok this was a design choice to avoid this bug present in 2.82:

Capture d’écran du 2020-05-28 14-20-11.png

Put simply we use the original face normal to avoid conflicting normals for multiple faces sharing the same original face (since there will only be 1 face dot/normal displayed).

So I would reconsider this as known issue.

For the subd modifier, this might make sense, but solidify and mirror really suffer from this.
Which commit was that, {a2d19c1f78}?

Just noting that this also breaks the mirror modifier as noted in #94826 (Face Normals display as NOT mirrored when Mirror Modifier is used) > In #77090#940084, @fclem wrote: > Ok this was a design choice to avoid this bug present in 2.82: > > ![Capture d’écran du 2020-05-28 14-20-11.png](https://archive.blender.org/developer/F8559903/Capture_d_écran_du_2020-05-28_14-20-11.png) > > Put simply we use the original face normal to avoid conflicting normals for multiple faces sharing the same original face (since there will only be 1 face dot/normal displayed). > > So I would reconsider this as known issue. For the subd modifier, this might make sense, but solidify and mirror really suffer from this. Which commit was that, {a2d19c1f78}?
Philipp Oeser changed title from Different face normals behaviour with solidify modifier to Generative modifiers (solidify, mirror) draw face normals from original face (wrong direction) 2022-01-12 15:11:25 +01:00
Member

Cant we be more distinct and only do this if we know they will be drawn in the same place?

Cant we be more distinct and only do this if we know they will be drawn in the same place?
Member

Added subscriber: @AdamJanz

Added subscriber: @AdamJanz
Member

Changed status from 'Archived' to: 'Needs Developer To Reproduce'

Changed status from 'Archived' to: 'Needs Developer To Reproduce'

@lichtwerk Thanks Philipp! Glad the devs are aware of this issue. I admit it's quite confusing to see inverted normals when modelling with the mirror modifier. A temporary workaround is to either turn off the "Cage" display on the modifier or enable "Face Orientation" in the Viewport Overlays so one can tell what normals are truly flipped.

A possible solution: would it be feasible to have the face normals draw on generated faces when "Cage" is enabled and only draw on original faces when "Cage" is disabled? This should also solve the original issue when a subsurf modifier is applied, with the added benefit of making more visual sense to the user (see images below):

Face normal on original faces.png

Face normal on generated faces.png

@lichtwerk Thanks Philipp! Glad the devs are aware of this issue. I admit it's quite confusing to see inverted normals when modelling with the mirror modifier. A temporary workaround is to either turn off the "Cage" display on the modifier or enable "Face Orientation" in the Viewport Overlays so one can tell what normals are truly flipped. A possible solution: would it be feasible to have the face normals draw on **generated faces when "Cage" is enabled** and only draw on original faces when "Cage" is disabled? This should also solve the original issue when a subsurf modifier is applied, with the added benefit of making more visual sense to the user (see images below): ![Face normal on original faces.png](https://archive.blender.org/developer/F12802413/Face_normal_on_original_faces.png) ![Face normal on generated faces.png](https://archive.blender.org/developer/F12802415/Face_normal_on_generated_faces.png)
Philipp Oeser removed the
Interest
Modeling
label 2023-02-09 15:29:15 +01:00
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
7 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#77090
No description provided.