Normal-Edit-modified mesh doesn't respect normals #60375

Closed
opened 2019-01-10 01:36:03 +01:00 by Rafael Navega · 17 comments

System Information
Operating system: Windows 8.1 x64
Graphics card: Nvidia GTX 960m, Intel HD Graphics 4600

Blender Version
Blender 2.79 official release

Short description of error
If you use the Normal Edit modifier on Directional mode on all vertices of a mesh, the mesh will not display according to the edited normals.

Exact steps for others to reproduce the error

  • Create a sphere, an empty and a lamp.
  • Add a Normal Edit modifier to the sphere, set it to Directional mode, turn on Parallel Normals and set the empty as target object.
  • Move the empty up, so every single normal of the mesh points up.
  • Apply the modifier and render the scene. The mesh will not display as it should.

I didn't post this in the Modifiers area because the modifiers and the mesh-displayed normals seem to be working right (see the image below with the purple normals), but the mesh doesn't respect the edited normals when rendered or when viewed in viewport-render mode or viewport-material mode.
normalEditBug1.png

If you set the viewport display mode to solid then it does look right: the entire mesh has one flat shade, since all normals point in the same direction.
normalEditBug2.png

**System Information** Operating system: Windows 8.1 x64 Graphics card: Nvidia GTX 960m, Intel HD Graphics 4600 **Blender Version** Blender 2.79 official release **Short description of error** If you use the Normal Edit modifier on Directional mode on all vertices of a mesh, the mesh will not display according to the edited normals. **Exact steps for others to reproduce the error** - Create a sphere, an empty and a lamp. - Add a Normal Edit modifier to the sphere, set it to Directional mode, turn on Parallel Normals and set the empty as target object. - Move the empty up, so every single normal of the mesh points up. - Apply the modifier and render the scene. The mesh will not display as it should. I didn't post this in the Modifiers area because the modifiers and the mesh-displayed normals seem to be working right (see the image below with the purple normals), but the mesh doesn't respect the edited normals when rendered or when viewed in viewport-render mode or viewport-material mode. ![normalEditBug1.png](https://archive.blender.org/developer/F6235287/normalEditBug1.png) If you set the viewport display mode to solid then it does look right: the entire mesh has one flat shade, since all normals point in the same direction. ![normalEditBug2.png](https://archive.blender.org/developer/F6235297/normalEditBug2.png)
Author

Added subscriber: @RNavega

Added subscriber: @RNavega

Added subscriber: @mont29

Added subscriber: @mont29

Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue (only ONE issue per report!), precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

Please follow our [submission template and guidelines](https:*developer.blender.org/maniphest/task/edit/form/1/), also read [these tips about bug reports](https:*wiki.blender.org/wiki/Process/Bug_Reports), and make a complete, valid bug report, with required info, precise description of the issue (only ONE issue per report!), precise steps to reproduce it, **small and simple** .blend and/or other files to do so if needed, etc.
Author

A test scene with the problem:
normalEditScene.blend

A test scene with the problem: [normalEditScene.blend](https://archive.blender.org/developer/F6264953/normalEditScene.blend)

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Bastien Montagne self-assigned this 2019-01-12 14:53:01 +01:00

Ok Thanks. I think what you mean by 'not render correctly' is the small (or not so small) dark faces on the left side near the lit/shadowed limit on the sphere? Those are terminator issues, caused by vertices normals being nearly aligned with the surface. That is not something you want to have if you expect consistent, predictable shading.

I guess more basic workbench drawing is not affected because it has some much simpler processing on lighting and shading.

In any case, see no bug here, just common CG limitation, thanks for the report anyway.

Ok Thanks. I think what you mean by 'not render correctly' is the small (or not so small) dark faces on the left side near the lit/shadowed limit on the sphere? Those are terminator issues, caused by vertices normals being nearly aligned with the surface. That is not something you want to have if you expect consistent, predictable shading. I guess more basic workbench drawing is not affected because it has some much simpler processing on lighting and shading. In any case, see no bug here, just common CG limitation, thanks for the report anyway.
Author

No, it's a bug.
The level of shading on a vertex depends on its normal.
If all vertices have the exact same normals, then all vertices should have the exact same shading, regardless of the shape of the mesh.

There should be no terminator (a transition between lit and unlit), because there's only one level of shading for the entire mesh.

I wish we could get a second opinion before archiving this.

No, it's a bug. The level of shading on a vertex depends on its normal. If all vertices have the exact same normals, then all vertices should have the exact same shading, regardless of the shape of the mesh. There should be no terminator (a transition between lit and unlit), because there's only one level of shading for the entire mesh. I wish we could get a second opinion before archiving this.

Added subscribers: @fclem, @brecht

Added subscribers: @fclem, @brecht

No it’s not a bug. Check for 'shading terminator' on the web…

Sure @brecht or @fclem can confirm, if you need a second opinion. :)

No it’s not a bug. Check for 'shading terminator' on the web… Sure @brecht or @fclem can confirm, if you need a second opinion. :)
Author

I put together a shader sandbox demo, for context:
https://goo.gl/ikYM35

Images based on that demo:
sameNormal01.png

On Blender 2.79, Cycles:
sameNormal02.png

I put together a shader sandbox demo, for context: https://goo.gl/ikYM35 Images based on that demo: ![sameNormal01.png](https://archive.blender.org/developer/F6275577/sameNormal01.png) On Blender 2.79, Cycles: ![sameNormal02.png](https://archive.blender.org/developer/F6275582/sameNormal02.png)

The terminator problem is about shadows based on actual geometry not matching fake shading normals. Without shadows there is no problem.

The terminator problem is about shadows based on actual geometry not matching fake shading normals. Without shadows there is no problem.
Author

Using 2.79, Blender Render engine, Material viewport-shade mode:

  1. Standard scene: sameNormalScene01.png

  2. Material viewport-shade mode (sun ray-traced shadow is set to a red color): sameNormalScene02.png

  3. Now using custom normals with the Normal Edit modifier: sameNormalScene03.png

  4. Material viewport-shade mode, using custom normals: sameNormalScene04.png

The visuals in #4 also happen with rendered Blender Render and rendered Cycles, and I'd imagine rendered Eevee too (untested).
If you need more information let me know. Thank you for triaging.

Using 2.79, Blender Render engine, Material viewport-shade mode: 1) Standard scene: ![sameNormalScene01.png](https://archive.blender.org/developer/F6279456/sameNormalScene01.png) 2) Material viewport-shade mode (sun ray-traced shadow is set to a red color): ![sameNormalScene02.png](https://archive.blender.org/developer/F6279460/sameNormalScene02.png) 3) Now using custom normals with the Normal Edit modifier: ![sameNormalScene03.png](https://archive.blender.org/developer/F6279463/sameNormalScene03.png) 4) Material viewport-shade mode, using custom normals: ![sameNormalScene04.png](https://archive.blender.org/developer/F6279466/sameNormalScene04.png) The visuals in #4 also happen with rendered Blender Render and rendered Cycles, and I'd imagine rendered Eevee too (untested). If you need more information let me know. Thank you for triaging.

This seems to confirm it is the shadow terminator problem, which we do not consider a bug.

This seems to confirm it is the shadow terminator problem, which we do not consider a bug.
Author

Hi Brecht.
Can you explain to me why the black faces in image #4 advance way further than the terminator seen in #2? (Considering that the scene layout is the same, just settings changed)

In fact, the black faces advance up to the specular highlights.

Hi Brecht. Can you explain to me why the black faces in image #4 advance way further than the terminator seen in #2? (Considering that the scene layout is the same, just settings changed) In fact, the black faces advance up to the specular highlights.
There's a paper about this here: https://fenix.tecnico.ulisboa.pt/downloadFile/1689468335601264/Its-Really-Not-a-Rendering-Bug-You-see....pdf
Author

This problem seems to be described in here:

But the "lock face winding" option was removed from the modifier UI in 2.79, it seems.

Edit: and thank you for the article.

This problem seems to be described in here: - https://developer.blender.org/T48576 - https://developer.blender.org/T55470 - https://developer.blender.org/T44180 - https://developer.blender.org/T51645 But the "lock face winding" option was removed from the modifier UI in 2.79, it seems. Edit: and thank you for the article.
Author

Ok, so for anyone coming to this in the future, set your custom normals with scripting rather than with the Normal Edit modifier. The modifier changes face winding and that's what causes the blocky patches, not a shading problem.

If you set your custom normals from a script (like an add-on tool) then the mesh renders as expected.

Ok, so for anyone coming to this in the future, set your custom normals [with scripting ](https://docs.blender.org/api/current/bpy.types.Mesh.html#bpy.types.Mesh.normals_split_custom_set_from_vertices) rather than with the Normal Edit modifier. The modifier changes face winding and that's what causes the blocky patches, not a shading problem. If you set your custom normals from a script (like an add-on tool) then the mesh renders as expected.
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
3 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#60375
No description provided.