Custom split normals & sharp edge edge behavior seems incorrect #110611

New Issue

Open

opened 2023-07-29 16:11:12 +02:00 by Nick-Kallen · 14 comments

Nick-Kallen commented

2023-07-29 16:11:12 +02:00

System Information
Operating system: Mac
Graphics card:

Blender Version
Broken: 3.6.1
Worked: 3.2

Hi,

I've noticed several changes to Blender custom (split) normal behavior between 3.2 and 3.6, using both the Python API and the user interface. I apologize if none of these are bugs, but some of this behavior seems possibly unintended to me.

First,

mesh.normals_split_custom_set(custom_normals)

Now automatically marks edges as sharp when the normals differ (or differ past a certain threshold?). This behavior is not in 3.2 and I'm not sure if it is correct or desirable. Is it supposed to be impossible to have split normals without (marked) sharp edges?

Second,

If a mesh has split normals around a sharp edge, removing the sharpness attribute on the edge (in the user interface or the api) throws away the split normal data. I'm attaching a picture:

Third,

Merge by distance in 3.2 used to preserve split normals if it joined two faces with distinct corner normals (but vertices within threshold). It now appears to average them or something.

I've attached a picture of issue #2 and a .blend file with before/afters of issue 2 and 3

**System Information** Operating system: Mac Graphics card: **Blender Version** Broken: 3.6.1 Worked: 3.2 Hi, I've noticed several changes to Blender custom (split) normal behavior between 3.2 and 3.6, using both the Python API and the user interface. I apologize if none of these are bugs, but some of this behavior seems possibly unintended to me. First, mesh.normals_split_custom_set(custom_normals) Now automatically marks edges as sharp when the normals differ (or differ past a certain threshold?). This behavior is not in 3.2 and I'm not sure if it is correct or desirable. Is it supposed to be impossible to have split normals without (marked) sharp edges? Second, If a mesh has split normals around a sharp edge, removing the sharpness attribute on the edge (in the user interface or the api) throws away the split normal data. I'm attaching a picture: Third, Merge by distance in 3.2 used to preserve split normals if it joined two faces with distinct corner normals (but vertices within threshold). It now appears to average them or something. I've attached a picture of issue #2 and a .blend file with before/afters of issue 2 and 3

blender-split-normal-bug-report.blend

1.6 MiB

clear-sharp.png

683 KiB

with-sharp.png

617 KiB

Nick-Kallen added the

labels 2023-07-29 16:11:13 +02:00

YimingWu added the

label 2023-07-30 10:19:41 +02:00

Pratik Borhade commented

2023-07-31 07:28:11 +02:00

Member

Hi, thanks for the report. Could you share raw file (with attributes)
It is recommended to split issues in individual reports.
Also: detailed steps for replicating the bug will reduce the investigation time.
A guideline for making a good bug report can be found at https://wiki.blender.org/wiki/Process/Bug_Reports

Hi, thanks for the report. Could you share raw file (with attributes) It is recommended to split issues in individual reports. Also: detailed steps for replicating the bug will reduce the investigation time. A guideline for making a good bug report can be found at https://wiki.blender.org/wiki/Process/Bug_Reports

Pratik Borhade added

Needs Information from User

and removed

labels 2023-07-31 07:28:20 +02:00

Nick-Kallen commented

2023-07-31 19:21:03 +02:00

Author

Hi,

I will try my best to provide a good bug report. I'm reporting a difference in behavior using 3.5.1 and 3.6.1. I discovered this while using the API. The exact same code/ addon produced the mesh (mesh-works.blend) in 3.5 and (mesh-doesn't-work) in 3.6.1

Open the attached file.
"Solid 2" should be in edit mode and all vertices are selected
Type "m" and select 'merge by distance'. Use default values:

0.0001 m, Leave "unselected" and "sharp edges" unchecked

Note that 350 vertices are removed
Note that one of the files the normals are preserved and in one of the files the normals are not preserved.

Hi, I will try my best to provide a good bug report. I'm reporting a difference in behavior using 3.5.1 and 3.6.1. I discovered this while using the API. The exact same code/ addon produced the mesh (mesh-works.blend) in 3.5 and (mesh-doesn't-work) in 3.6.1 1. Open the attached file. 2. "Solid 2" should be in edit mode and all vertices are selected 3. Type "m" and select 'merge by distance'. Use default values: - 0.0001 m, Leave "unselected" and "sharp edges" unchecked 4. Note that 350 vertices are removed 5. Note that one of the files the normals are preserved and in one of the files the normals are not preserved.

merge-doesnt-work.blend

854 KiB

merge-works.blend

850 KiB

Nick-Kallen commented

2023-07-31 19:28:42 +02:00

Author

Here is another way of looking at the bug. I'm attaching two files. They are constructed via the same addon, the exact same API functions, in Blender 3.5 and in 3.6

One of them (3.6) has edges marked as sharp automatically, without an explicit API calls to mark sharp edges. It discards split normals at edges not marked sharp, which I believe is incorrect behavior.

Here is another way of looking at the bug. I'm attaching two files. They are constructed via the same addon, the exact same API functions, in Blender 3.5 and in 3.6 One of them (3.6) has edges marked as sharp automatically, without an explicit API calls to mark sharp edges. It discards split normals at edges not marked sharp, which I believe is incorrect behavior.

Screen Shot 2023-07-31 at 19.27.55.png

1.6 MiB

made-in-3-5.blend

854 KiB

Screen Shot 2023-07-31 at 19.25.21.png

1.7 MiB

made-in-3-6.blend

856 KiB

Screen Shot 2023-07-31 at 19.27.55.png

Screen Shot 2023-07-31 at 19.25.21.png

Nick-Kallen commented

2023-07-31 20:00:39 +02:00

Author

This seems like a related issue

https://projects.blender.org/blender/blender/issues/109599 This seems like a related issue

Nick-Kallen commented

2023-08-02 22:38:15 +02:00

Author

Hi,

Is this still not clear enough as a bug report?

Hi, Is this still not clear enough as a bug report?

Pratik Borhade commented

2023-08-03 08:55:51 +02:00

Member

Hi, thanks for the info. This indeed looks relevant to (custom normals) #109599, closing.

Hi, thanks for the info. This indeed looks relevant to (custom normals) #109599, closing.

Pratik Borhade closed this issue

2023-08-03 08:55:54 +02:00

Blender Bot added

and removed

Needs Information from User

labels 2023-08-03 08:55:55 +02:00

Nick-Kallen commented

2023-08-03 12:25:52 +02:00

Author

Hi,

Respectfully, I wonder if closing this bug is the right approach. I reviewed Hans' optimization in 3.6 to the way split normals are handled. It is a significant (and worthwhile!) change and possibly (likely?) it introduced several bugs. I want to note that in addition to the OBJ and FBX importer being broken with split normals #109599 , the following behaviors have changed in 3.6 from 3.5:

mesh.normals_split_custom_set() is now marking sharp edges and it wasn't before (probably a bug)
mesh.normals_split_custom_set() is incorrectly marking sharp edges, failing to mark edges that are actually sharp as sharp (definitely a bug)
mesh.normals_split_custom_set() is discarding split normals where edges are not sharp (definitely a bug)
remove_doubles() is averaging normals of merged faces, whereas before it preserved normals of source faces as split normals (probably a bug)

For the things that are "probably" a bug, they are seemingly undocumented changes to behavior between 3.6 and 3.5 (I've reviewed the changelog),they are probably unintended, and at least for my use case they are undesirable.

Thanks

Hi, Respectfully, I wonder if closing this bug is the right approach. I reviewed Hans' optimization in 3.6 to the way split normals are handled. It is a significant (and worthwhile!) change and possibly (likely?) it introduced several bugs. I want to note that in addition to the OBJ and FBX importer being broken with split normals https://projects.blender.org/blender/blender/issues/109599 , the following behaviors have changed in 3.6 from 3.5: 1. mesh.normals_split_custom_set() is now marking sharp edges and it wasn't before (probably a bug) 2. mesh.normals_split_custom_set() is incorrectly marking sharp edges, failing to mark edges that are actually sharp as sharp (definitely a bug) 3. mesh.normals_split_custom_set() is discarding split normals where edges are not sharp (definitely a bug) 4. remove_doubles() is averaging normals of merged faces, whereas before it preserved normals of source faces as split normals (probably a bug) For the things that are "probably" a bug, they are seemingly undocumented changes to behavior between 3.6 and 3.5 (I've reviewed the changelog),they are probably unintended, and at least for my use case they are undesirable. Thanks

Nick-Kallen reopened this issue

2023-08-03 12:25:55 +02:00

Blender Bot added

and removed

labels 2023-08-03 12:25:57 +02:00

Iliya Katushenock commented

2023-08-03 12:27:59 +02:00

Member

@HooglyBoogly /^

@HooglyBoogly /^

Pratik Borhade referenced this issue from blender/blender-addons

2023-08-08 10:42:21 +02:00

fbx import normal error in blender 3.6 #104826

Philipp Oeser commented

2023-09-18 16:53:37 +02:00

Member

I believe this report has to be cleaned up in some ways:

the comments talk about a difference between 3.5 and 3.6 (whereas the report description has the difference between 3.2 and 3.6)
regarding removing the sharp attribute: I cannot spot a difference between any of those versions when doing this from the UI: in all cases, the custom normals are averaged, not preserved
regarding merging by distance: I cannot spot a difference between any of those versions when doing this from the UI: in all cases, the custom normals preserved, not averaged

If this is solely about the usage in the python API, please provide a minimal .blend file including a simple script that reproduces those issues (or provide the Addon which reproduces the issue along with exact steps to reproduce this). If this is about the usage in the UI, please also provide more exact steps from blender-split-normal-bug-report.blend for any of the issues.

I believe this report has to be cleaned up in some ways: - the comments talk about a difference between 3.5 and 3.6 (whereas the report description has the difference between 3.2 and 3.6) - regarding removing the sharp attribute: I cannot spot a difference between any of those versions when doing this from the UI: in all cases, the custom normals are averaged, not preserved - regarding merging by distance: I cannot spot a difference between any of those versions when doing this from the UI: in all cases, the custom normals preserved, not averaged If this is solely about the usage in the python API, please provide a minimal .blend file including a simple script that reproduces those issues (or provide the Addon which reproduces the issue along with exact steps to reproduce this). If this is about the usage in the UI, please also provide more exact steps from `blender-split-normal-bug-report.blend` for any of the issues.

Philipp Oeser added

Needs Information from User

and removed

labels 2023-09-18 16:53:48 +02:00

Pratik Borhade commented

2023-09-30 12:33:47 +02:00

Member

@Nick-Kallen , can you verify whether this is fixed with #109599 / 7449f0e14caecd70f093aa7c6ba02c5d6d78527e?

@Nick-Kallen , can you verify whether this is fixed with #109599 / 7449f0e14caecd70f093aa7c6ba02c5d6d78527e?

Nick-Kallen commented

2023-09-30 17:16:22 +02:00

Author

Hi,

I haven't done a thorough evaluation but a quick check in Blender 4.1 alpha, things look quite nice! Blender 3.6 shown by comparison

Hi, I haven't done a thorough evaluation but a quick check in Blender 4.1 alpha, things look quite nice! Blender 3.6 shown by comparison

Blender 4.1 alpha.png

1.7 MiB

Blender 3.6 LTS.png

1.9 MiB

Blender 4.1 alpha.png

Blender 3.6 LTS.png

Nick-Kallen commented

2023-09-30 17:35:17 +02:00

Author

OK but Unfortunately the behaviour still differs from 3.5. You can see that the API is automatically marking edges as sharp in the pictures posted previously (3.6 and 4.1) but here in screenshot from 3.5 the edges are not marked sharp automatically. To me this change in behaviour is undesirable. This is faceted CAD data, I would like to be able to mark edges sharp myself. Clearing sharp discards split normals, so that isn't an option. I will try to narrow this down to code that you can execute directly. Let me get back to you.

OK but Unfortunately the behaviour still differs from 3.5. You can see that the API is automatically marking edges as sharp in the pictures posted previously (3.6 and 4.1) but here in screenshot from 3.5 the edges are not marked sharp automatically. To me this change in behaviour is undesirable. This is faceted CAD data, I would like to be able to mark edges sharp myself. Clearing sharp discards split normals, so that isn't an option. I will try to narrow this down to code that you can execute directly. Let me get back to you.

Screenshot 2023-09-30 at 08.30.15.png

1.9 MiB

Screenshot 2023-09-30 at 08.30.15.png

Pratik Borhade commented

2023-10-03 13:19:04 +02:00

Member

Thanks, could you specify importer you've used for that?
Also share information @lichtwerk requested in #110611 (comment)

Thanks, could you specify importer you've used for that? Also share information @lichtwerk requested in https://projects.blender.org/blender/blender/issues/110611#issuecomment-1024898

Nick-Kallen commented

2023-10-03 15:59:39 +02:00

Author

Hi,

This is not using an importer but using the API. The relevant source code is here:

b1f977c405/handler.py (L128)

To reiterate:
. The behavior is the API not the user interface
. The behavior changed in 3.6. That is, 3.5 and before (... 3.2) seem "correct" to me.

I will try to give you a simple executable test case soon. But to be clear, all you need to do is create an (quad/ngon) object with

 mesh.use_auto_smooth = True
 mesh.normals_split_custom_set(...)

And there are behaviour differences starting with 3.6. (e.g., it is marking sharp where it wasn't before, etc).

Hi, This is not using an importer but using the API. The relevant source code is here: https://github.com/nkallen/plasticity-blender-addon/blob/b1f977c4053724ad67982e73b3dcbb554e4ecab6/handler.py#L128 To reiterate: . The behavior is the API not the user interface . The behavior changed in 3.6. That is, 3.5 and before (... 3.2) seem "correct" to me. I will try to give you a simple executable test case soon. But to be clear, all you need to do is create an (quad/ngon) object with ``` mesh.use_auto_smooth = True mesh.normals_split_custom_set(...) ``` And there are behaviour differences starting with 3.6. (e.g., it is marking sharp where it wasn't before, etc).

Philipp Oeser added

and removed

Needs Information from User

labels 2023-10-11 12:47:49 +02:00

Pratik Borhade referenced this issue

2023-11-02 08:03:41 +01:00

Python API: Meshes with "Auto Smooth" applied get data overwriten when applying "Auto Smooth" in the interface #114292

Surasia referenced this issue

2023-11-05 16:44:08 +01:00

Python API: Meshes with "Auto Smooth" applied get data overwriten when applying "Auto Smooth" in the interface #114292

Iliya Katushenock added the

label 2024-04-07 22:21:28 +02:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

4 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#110611

No description provided.