Custom Normals: some operations that alter topology (bisect, loopcut, subdivide, knife, triangulate modifier) destroy them while other operations (e.g. Connect Vertex Path, triangulate operator) preserve them #97698

New Issue

Anthony Diggle · 2022-04-29T13:02:25+02:00

Anthony Diggle commented

2022-04-29 13:02:25 +02:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.65

Blender Version
Broken: version: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: cc66d1020c
Worked: unknown

Short description of error
Mesh bisect generates incorrect normals when applied to a face generated using bevel with "harden normals" applied

Exact steps for others to reproduce the error

Start with the default cube
In the cube properties, enable auto smooth normals (Object Data -> Normals -> Auto Smooth)
Enter edit mode
Select one edge and bevel it
In the operator panel, ensure that "harden normals" is enabled
Select the whole model
Bisect the cube so the bevelled edge is split in half

The bad normals should now be visible. You can enable normal indicators in Overlays -> Normals -> Split face normals (the second option of the three icons). You can also go to object mode to remove the wireframe and make the bad shading more obvious.

bevel and bisect.mp4

Note that traditionally, topology altering operations were not expected to preserve custom normals, see for example

#69290 (Loop cut and knife tools makes wrong shading on the mesh)
#53763 (Operations that alter topology (e.g. Mirror modifier AND mirror operator, loopcut, subdivide, knife) destroy custom normals)

Then there has been 93c8955a72 which was a nice improvement for some operators (but was missing others afaict).
(check usages of BM_custom_loop_normals_to_vector_layer)

So this now leaves us in the situation which feels puzzling/inconsistent:
On the reported geometry for example Connect Vertex Path works as expected, whereas Knife doesnt:
#97698.webm

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.65 **Blender Version** Broken: version: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: `cc66d1020c` Worked: unknown **Short description of error** Mesh bisect generates incorrect normals when applied to a face generated using bevel with "harden normals" applied **Exact steps for others to reproduce the error** 1. Start with the default cube 2. In the cube properties, enable auto smooth normals (Object Data -> Normals -> Auto Smooth) 3. Enter edit mode 4. Select one edge and bevel it 5. In the operator panel, ensure that "harden normals" is enabled 6. Select the whole model 7. Bisect the cube so the bevelled edge is split in half The bad normals should now be visible. You can enable normal indicators in Overlays -> Normals -> Split face normals (the second option of the three icons). You can also go to object mode to remove the wireframe and make the bad shading more obvious. [bevel and bisect.mp4](https://archive.blender.org/developer/F13037495/bevel_and_bisect.mp4) Note that traditionally, topology altering operations were not expected to preserve custom normals, see for example - #69290 (Loop cut and knife tools makes wrong shading on the mesh) - #53763 (Operations that alter topology (e.g. Mirror modifier AND mirror operator, loopcut, subdivide, knife) destroy custom normals) Then there has been 93c8955a72 which was a nice improvement for some operators (but was missing others afaict). (check usages of `BM_custom_loop_normals_to_vector_layer`) So this now leaves us in the situation which feels puzzling/inconsistent: On the reported geometry for example `Connect Vertex Path` works as expected, whereas `Knife` doesnt: [#97698.webm](https://archive.blender.org/developer/F13049147/T97698.webm)

blender-admin commented

2022-04-29 13:02:25 +02:00

#104244 was marked as duplicate of this issue

Anthony Diggle commented

2022-04-29 13:02:26 +02:00

Added subscriber: @fuseinabowl

Pratik Borhade commented

2022-04-29 17:47:01 +02:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2022-04-29 17:47:58 +02:00

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

Philipp Oeser commented

2022-05-02 08:02:36 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-05-02 08:02:36 +02:00

This is true for many modeling operations like knife or even subdivide.

Philipp Oeser changed title from ~~Bisect generates incorrect normals when face has custom normals~~ to Some operations that alter topology (bisect, loopcut, subdivide, knife) destroy custom normals while other operations (e.g. Connect Vertex Path) preserve them

2022-05-03 14:38:18 +02:00

Paul Kotelevets commented

2022-05-04 00:56:56 +02:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2022-05-04 00:56:56 +02:00

In #97698#1349938, @lichtwerk wrote:
This is true for many modeling operations like knife or even subdivide.

Made some brief test, it looks like harden normals option brings a lot to this issue, when bevel is applied to geometry without previously assigned smooth shading to faces.
Can you confirm this by repeating all the same steps that are shown in the description, but applying ctrl+F - Shade smooth to all faces of the cube before bevel operation?

> In #97698#1349938, @lichtwerk wrote: > This is true for many modeling operations like knife or even subdivide. Made some brief test, it looks like **harden normals** option brings a lot to this issue, when bevel is applied to geometry without previously assigned smooth shading to faces. Can you confirm this by repeating all the same steps that are shown in the description, but applying **ctrl+F - Shade smooth** to all faces of the cube before bevel operation?

Anthony Diggle commented

2022-05-05 01:33:12 +02:00

In #97698#1351371, @1D_Inc wrote:

Can you confirm this by repeating all the same steps that are shown in the description, but applying ctrl+F - Shade smooth to all faces of the cube before bevel operation?

This looks better for the cuts in the middle of the bevel but doesn't completely fix the issue: On the cut across the hardened edge of the bevel there are different normals on the upper faces and the lower faces. The difference in shading is not very visible in the video, but you can see that the vertex has two normals right at the end.

smooth then bevel and knife.mp4

> In #97698#1351371, @1D_Inc wrote: > > Can you confirm this by repeating all the same steps that are shown in the description, but applying **ctrl+F - Shade smooth** to all faces of the cube before bevel operation? This looks better for the cuts in the middle of the bevel but doesn't completely fix the issue: On the cut across the hardened edge of the bevel there are different normals on the upper faces and the lower faces. The difference in shading is not very visible in the video, but you can see that the vertex has two normals right at the end. [smooth then bevel and knife.mp4](https://archive.blender.org/developer/F13052194/smooth_then_bevel_and_knife.mp4)

Paul Kotelevets commented

2022-05-05 04:27:42 +02:00

Well, yes, there is a normal's break, but this is the way sharp edges are supposed to work.
Sharp edges breaks normals, so this is implied functionality.

Well, yes, there is a normal's break, but this is the way sharp edges are supposed to work. Sharp edges breaks normals, so this is implied functionality.

Philipp Oeser commented

2022-05-05 10:14:28 +02:00

Yes, smooth shade prior improves this.
But... should it? This still shows custom normals are not really taken into account here, no?

Yes, smooth shade prior improves this. But... should it? This still shows custom normals are not really taken into account here, no?

Anthony Diggle commented

2022-05-05 14:28:38 +02:00

In #97698#1352317, @1D_Inc wrote:
Well, yes, there is a normal's break, but this is the way sharp edges are supposed to work.

As a user, I expected the knife tool to not modify normals. In this case, the sharp edge has the same normal on both sides of the edge before the operation, but afterwards the created vertex has split normals. I expected all the vertex's face corners to point the same direction as the edge did (exactly -X).

I don't think this conflicts with how you're saying sharp edges work (please let me know if I've misunderstood), but I do think that the knife shouldn't introduce a split normal across a sharp edge if there wasn't one previously.

> In #97698#1352317, @1D_Inc wrote: > Well, yes, there is a normal's break, but this is the way sharp edges are supposed to work. As a user, I expected the knife tool to not modify normals. In this case, the sharp edge has the same normal on both sides of the edge before the operation, but afterwards the created vertex has split normals. I expected all the vertex's face corners to point the same direction as the edge did (exactly -X). I don't think this conflicts with how you're saying sharp edges work (please let me know if I've misunderstood), but I do think that the knife shouldn't introduce a split normal across a sharp edge if there wasn't one previously.

Paul Kotelevets commented

2022-05-05 22:10:33 +02:00

In #97698#1352406, @lichtwerk wrote:
Yes, smooth shade prior improves this.
But... should it? This still shows custom normals are not really taken into account here, no?

Yes, this is a case custom normals are not taken into account, so it is localized.
But it is strange that Vertex Connect Path works even in that case, unlike most of operators.

> In #97698#1352406, @lichtwerk wrote: > Yes, smooth shade prior improves this. > But... should it? This still shows custom normals are not really taken into account here, no? Yes, this is a case custom normals are not taken into account, so it is localized. But it is strange that Vertex Connect Path works even in that case, unlike most of operators.

Mysteryem commented

2022-06-26 18:24:52 +02:00

Added subscriber: @Mysteryem-2

Mysteryem commented

2022-06-26 18:24:52 +02:00

To add to this, the bpy.ops.mesh.separate operator has mixed results that differ based on the type specified in the operator, whether the polygons affected have smooth or flat shading prior to being given custom normals and the current mode of the mesh object being operated on.

There is no column for type='SELECTED' in Object mode, because it can't be used in Object mode.
The change in behaviour between 2.90.1 and 2.91.0 for type='LOOSE' appears to have been from https://developer.blender.org/rB67c7fe6ad62e18b78ef70428e8eead8fdba65100 where Edit mode was fixed, but I don't know what caused the change between 2.80 and 2.81 and the change between 2.93.9 and 3.0.0.
The following Blend file has a specifically set up mesh that is half flat shaded and half smooth shaded, with scripts to apply a Normal Edit modifier to it and then for each case of Edit/Object mode and each type argument run the separate operator. (file was created on 2.80 so can be opened in all of the mentioned versions)
SeparateTest.blend

To add to this, the bpy.ops.mesh.separate operator has mixed results that differ based on the `type` specified in the operator, whether the polygons affected have smooth or flat shading prior to being given custom normals and the current mode of the mesh object being operated on. ![image.png](https://archive.blender.org/developer/F13231016/image.png) ![image.png](https://archive.blender.org/developer/F13231055/image.png) There is no column for type='SELECTED' in Object mode, because it can't be used in Object mode. The change in behaviour between 2.90.1 and 2.91.0 for `type='LOOSE'` appears to have been from https://developer.blender.org/rB67c7fe6ad62e18b78ef70428e8eead8fdba65100 where Edit mode was fixed, but I don't know what caused the change between 2.80 and 2.81 and the change between 2.93.9 and 3.0.0. The following Blend file has a specifically set up mesh that is half flat shaded and half smooth shaded, with scripts to apply a Normal Edit modifier to it and then for each case of Edit/Object mode and each `type` argument run the `separate` operator. (file was created on 2.80 so can be opened in all of the mentioned versions) [SeparateTest.blend](https://archive.blender.org/developer/F13231026/SeparateTest.blend)

Philipp Oeser changed title from ~~Some operations that alter topology (bisect, loopcut, subdivide, knife) destroy custom normals while other operations (e.g. Connect Vertex Path) preserve them~~ to Custom Normals: some operations that alter topology (bisect, loopcut, subdivide, knife, triangulate modifier) destroy them while other operations (e.g. Connect Vertex Path, triangulate operator) preserve them

2023-01-31 09:45:25 +01:00

Philipp Oeser commented

2023-01-31 09:47:21 +01:00

Added subscriber: @alleysoft

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Custom Normals: some operations that alter topology (bisect, loopcut, subdivide, knife, triangulate modifier) destroy them while other operations (e.g. Connect Vertex Path, triangulate operator) preserve them #97698