Mesh Normals and Auto Smooth in 4.1 #93551

New Issue

Open

opened 2021-12-01 19:29:14 +01:00 by Hans Goudey · 39 comments

Hans Goudey commented 2021-12-01 19:29:14 +01:00

Member

Copy Link

Background

This document describes changes to the calculation of mesh normals meant to address some of the performance and usability problems, non-exhaustively listed here:

• Vertex normals are always calculated, even if the shading is sharp and they are unnecessary.
  • Similarly, when auto smooth is enabled, per-face-corner normals are always calculated, even if the mesh is shaded entirely smooth or sharp.
• "Auto Smooth" is a mesh property, even though it can be exposed more intuitively as an action applied to meshes.
  • As an action, auto smooth is unified with other ways to control the sharpness of mesh edges and faces, unifying the system and removing the need to learn another method of control.
• The extra step of enabling auto smooth is required to have mixed sharp and smooth shading.
  • For example, marking sharp edges on a smooth shaded mesh doesn't do anything. That's why some modifiers have to tell you to "Enable Auto Smooth in mesh properties!"
• Without further configuration, auto smooth always recalculates sharp edges. With deforming meshes, it generally makes no sense to change sharp edge flags over deformation.
  • Even understanding this issue is confusing because, as mentioned, auto smooth is portrayed as a property rather than an action.
• Using custom normals forces calculating normals per-face-corner, even in cases where splitting normals across edges isn't necessary. This is much worse for performance.
• Custom normals are always stored as short2 in a special coordinate space defined by the automatically calculated normals. Converting to and from this coordinate space is expensive.
  • This forces calculating automatic face corner normals to view them, even if the custom normals were hypothetically generated procedurally.
  • Custom normal spaces also make per-vertex custom normals impossible.

Solutions

Procedural Custom Normals

Two new geometry nodes features can allow reading and writing custom normals in a procedural context.

1. Set Custom Normals has a choice between creating vertex and face corner normals, a vector input, and an option for whether to write normals in the stable-over-deformation custom normals space (the one currently used for custom normals), or as regular vectors.
   • The last part represents another new feature. If they are stored in this "plain vector" format, further use of normals doesn't have to recalculate anything, compared to the existing custom space system, where the automatic normals need to be calculated to find the actual custom normal vectors. That works well when normals are set procedurally at the end of modifier stack anyway.
   • With the vertex domain, only the plain vector format would be supported, unless we wanted to add another normal space option for vertices.
2. The True Normal output/node adds to the existing "Normal" node. It outputs normals without custom normals.
   • This could be a new node, or a new socket to the existing "Normal" node.
   • Versioning would replace existing nodes with this output.

For the "plain vector" format, the regular float3 attribute type can be used. Potentially, meta-data could tell geometry processing algorithms to interpolate the attribute differently if they support it (a simple case is the "Transform Geometry" node). But generally the existing custom normals space short2 storage should be used if better interpolation is necessary.

Curve Normals

Custom normals should be possible for curves too, though with a separate node since the options are different. The existing "Set Curve Normal" node can be used to set custom per-point normals. These may be automatically changed later to make them perpendicular with the tangents.

The creation of a per-curve "up" vector attribute to influence the starting direction used for normals calculated automatically with the existing modes could be supported too.

Replace "Auto Smooth"

The existing auto smooth option

By writing to the sharp_edge attribute, we can have the same effect as auto smooth with a geometry nodes modifier. Versioning code replaces the property with this modifier.

The modifier that replaces the property

The modifier keeps the same behavior as before, but often it isn't necessary to change the sharp edges in the modifier stack-- doing it once in edit mode is enough. Similarly, applying the modifier can avoid changing sharp edges over deformation and give better performance. Using a modifier also gives an intuitive way to disable the effect in the viewport, without requiring drivers.

This existing edit mode operator is also useful

To keep the existing behavior accessible, an new operator with the same "Auto Smooth" name can add this modifier. Eventually though, the node group should be moved to the Essentials asset bundle. That can happen as soon as we have a quick way to add node groups assets as modifiers in the property editor.

Combined with the next auto-domain-choice change, this gives proper control of split face corner normals to geometry nodes. Without the auto smooth option, joining meshes with different sharp/smooth attributes would just work, without relying on the first mesh having auto smooth set. Having the final sharp edge status as part of the visible state of the mesh is essential to make this work.

Using modifiers for this sort of behavior unifies Blender's design to use user-controllable geometry nodes for geometry processing operations. This design is more obvious in the big picture considering a future where "everything nodes" improves the consistency, power, and reliability of Blender features, makes UX more consistent, and improves the development process.

Automatically Determine Necessary Domain

With the sharp_edge and sharp_face boolean attributes, we have all the information we need to know whether we need normals per-face, per-vertex, or per-face-corner. This information is important, because the performance difference between the three is quite large. When the mesh is entirely sharp, face normals are enough. When the mesh is entirely smooth, we need to calculate vertex normals. If there is a mix, we need "split" face corner normals.

This change makes the "Auto Smooth" property unnecessary, since one of its main uses was to avoid the performance cost of face corner normals. It's easy to figure the necessary normals automatically, completely removing this step in using mixed smooth and sharp shading, without paying a performance cost in the simpler cases.

The previous workflow:

• Enable auto smooth
• Set auto smooth angle, or set to 180 degrees for complete manual control
• Run "Shade smooth"
• Mark some edges sharp

The new workflow:

• Run "Shade Smooth"
• Mark some edges sharp

Partially this is just a performance optimization (enabled by the removal of auto smooth as a property), but it's also a conceptual change. After the change, the sharp shading status is clearly part of the visible state of the mesh that can be "frozen", it's only the shading that's automatic. Before, both of those things were automatic, happening only internally.

FAQ / Common Concerns

1. This disrupts implicit instancing of objects using the same mesh
   • Implicit sharing of mesh data negates negative aspects of this.
   • Applying the modifier removes the issue completely. Since there aren't any other modifiers, there shouldn't be much of a downside to this anyway.
   • In the future, the "auto instancing" could take identical modifiers into account.
2. Managing auto smoothing on many objects may get more difficult
   • As more features are tied to geometry nodes and modifiers recently, this is clearly a more general issue.
   • It's easy to imagine features to add or remove a modifier on all selected objects.
   • The existing "hold alt" feature already works with modifier visibility.
   • The "Copy to Selected" modifier feature is also important here.
3. How accessible is the feature now?
   • Extending add modifier menu with assets (#111717) combined with searching of menus and remembering recent searches (all planned for 4.0) addresses this
   • While the location of auto smoothing moves, and has to be relearned, the consistency and flexibility is worth it
4. This impacts exporter's special features relating to auto smooth
   • It is true that handling auto smooth as a special feature in exporters becomes more difficult. My hope is that the simplification of behavior (no need for the option, just working with sharp tags, etc.) offsets the downside of this.
5. There is extra "stuff" in geometry nodes modifier panel
   • The extra unused panels can be removed one the node panels features make their way to the modifier.
   • The data-block picker doesn't have to be displayed when adding modifiers from assets, but that is lower priority.

Technical Info

Sharp Edges	Sharp Face	Normal Domain	Approximate Cost
All True	All True	Face	1.0x
Any	All True	Face	1.0x
All True	Any	Face	1.0x
All False	All False	Vertex	4.0x
Mixed	Mixed	Face Corner	10.0x

A function eAttrDomain Mesh::normal_domain_all_info() const; gives us this information. We can use its result to optimize normal sampling in many places. Viewport drawing would be one important example.

Corner normals are now shared with a SharedCache, meaning they don't have to be recomputed just because a mesh is copied.

Implementation TODOs

• Double check shape key export workflow
• Update PR description to be more clear about what parts of the Python API change and to reference the modifier add menu changes
• "Unpublish" the "Smooth by Angle" asset in 4.0
• Test PR with module members
• Work on viewport normals simplification option that skips corner normals and custom normals HooglyBoogly/blender#5
• Iterate on the "Smooth by Angle" asset
  • Potentially not exactly reimplement auto smooth behavior
  • Potentially add options to give higher level access to different behavior
  • Reconsider name based on above decisions
• Start implementation of custom normals geometry nodes

Related PRs: #108014

## Background This document describes changes to the calculation of mesh normals meant to address some of the performance and usability problems, non-exhaustively listed here: - Vertex normals are always calculated, even if the shading is sharp and they are unnecessary. - Similarly, when auto smooth is enabled, per-face-corner normals are always calculated, even if the mesh is shaded entirely smooth or sharp. - "Auto Smooth" is a mesh property, even though it can be exposed more intuitively as an **action** applied to meshes. - As an action, auto smooth is unified with other ways to control the sharpness of mesh edges and faces, unifying the system and removing the need to learn another method of control. - The **extra step** of enabling auto smooth is required to have mixed sharp and smooth shading. - For example, marking sharp edges on a smooth shaded mesh doesn't do anything. That's why some modifiers have to tell you to "Enable Auto Smooth in mesh properties!" - Without further configuration, auto smooth **always recalculates** sharp edges. With deforming meshes, it generally makes no sense to change sharp edge flags over deformation. - Even understanding this issue is confusing because, as mentioned, auto smooth is portrayed as a property rather than an action. - Using custom normals forces calculating normals per-face-corner, even in cases where splitting normals across edges isn't necessary. This is much worse for performance. - Custom normals are always stored as `short2` in a special coordinate space defined by the automatically calculated normals. Converting to and from this coordinate space is expensive. - This forces calculating automatic face corner normals to view them, even if the custom normals were hypothetically generated procedurally. - Custom normal spaces also make per-vertex custom normals impossible. ## Solutions ### Procedural Custom Normals Two new geometry nodes features can allow reading and writing custom normals in a procedural context. 1. **Set Custom Normals** has a choice between creating vertex and face corner normals, a vector input, and an option for whether to write normals in the stable-over-deformation custom normals space (the one currently used for custom normals), or as regular vectors. - The last part represents another new feature. If they are stored in this "plain vector" format, further use of normals doesn't have to recalculate anything, compared to the existing custom space system, where the automatic normals need to be calculated to find the actual custom normal vectors. That works well when normals are set procedurally at the end of modifier stack anyway. - With the vertex domain, only the plain vector format would be supported, unless we wanted to add another normal space option for vertices. 2. The **True Normal** output/node adds to the existing "Normal" node. It outputs normals without custom normals. - This could be a new node, or a new socket to the existing "Normal" node. - Versioning would replace existing nodes with this output. For the "plain vector" format, the regular `float3` attribute type can be used. Potentially, meta-data could tell geometry processing algorithms to interpolate the attribute differently if they support it (a simple case is the "Transform Geometry" node). But generally the existing custom normals space `short2` storage should be used if better interpolation is necessary. #### Curve Normals Custom normals should be possible for curves too, though with a separate node since the options are different. The existing "Set Curve Normal" node can be used to set custom per-point normals. These may be automatically changed later to make them perpendicular with the tangents. The creation of a per-curve "up" vector attribute to influence the starting direction used for normals calculated automatically with the existing modes could be supported too. ### Replace "Auto Smooth"  _The existing auto smooth option_ By writing to the `sharp_edge` attribute, we can have the same effect as auto smooth with a geometry nodes modifier. Versioning code replaces the property with this modifier.  _The modifier that replaces the property_ The modifier keeps the same behavior as before, but often it isn't necessary to change the sharp edges in the modifier stack-- doing it once in edit mode is enough. Similarly, applying the modifier can avoid changing sharp edges over deformation and give better performance. Using a modifier also gives an intuitive way to disable the effect in the viewport, without requiring drivers.  _This existing edit mode operator is also useful_ To keep the existing behavior accessible, an new operator with the same "Auto Smooth" name can add this modifier. Eventually though, the node group should be moved to the Essentials asset bundle. That can happen as soon as we have a quick way to add node groups assets as modifiers in the property editor. Combined with the next auto-domain-choice change, this gives proper control of split face corner normals to geometry nodes. Without the auto smooth option, joining meshes with different sharp/smooth attributes would just work, without relying on the first mesh having auto smooth set. Having the final sharp edge status as part of the visible state of the mesh is essential to make this work. Using modifiers for this sort of behavior unifies Blender's design to use user-controllable geometry nodes for geometry processing operations. This design is more obvious in the big picture considering a future where "everything nodes" improves the consistency, power, and reliability of Blender features, makes UX more consistent, and improves the development process. ### Automatically Determine Necessary Domain With the `sharp_edge` and `sharp_face` boolean attributes, we have all the information we need to know whether we need normals per-face, per-vertex, or per-face-corner. This information is important, because the performance difference between the three is quite large. When the mesh is entirely sharp, face normals are enough. When the mesh is entirely smooth, we need to calculate vertex normals. If there is a mix, we need "split" face corner normals. This change makes the "Auto Smooth" property unnecessary, since one of its main uses was to avoid the performance cost of face corner normals. It's easy to figure the necessary normals automatically, completely removing this step in using mixed smooth and sharp shading, without paying a performance cost in the simpler cases. The previous workflow: - Enable auto smooth - Set auto smooth angle, or set to 180 degrees for complete manual control - Run "Shade smooth" - Mark some edges sharp The new workflow: - Run "Shade Smooth" - Mark some edges sharp Partially this is just a performance optimization (enabled by the removal of auto smooth as a property), but it's also a conceptual change. After the change, the sharp shading status is clearly part of the visible state of the mesh that can be "frozen", it's only the shading that's automatic. Before, both of those things were automatic, happening only internally. ## FAQ / Common Concerns 1. This disrupts implicit instancing of objects using the same mesh - Implicit sharing of mesh data negates negative aspects of this. - Applying the modifier removes the issue completely. Since there aren't any other modifiers, there shouldn't be much of a downside to this anyway. - In the future, the "auto instancing" could take identical modifiers into account. 2. Managing auto smoothing on many objects may get more difficult - As more features are tied to geometry nodes and modifiers recently, this is clearly a more general issue. - It's easy to imagine features to add or remove a modifier on all selected objects. - The existing "hold alt" feature already works with modifier visibility. - The "Copy to Selected" modifier feature is also important here. 3. How accessible is the feature now? - Extending add modifier menu with assets (#111717) combined with searching of menus and remembering recent searches (all planned for 4.0) addresses this - While the location of auto smoothing moves, and has to be relearned, the consistency and flexibility is worth it 4. This impacts exporter's special features relating to auto smooth - It is true that handling auto smooth as a special feature in exporters becomes more difficult. My hope is that the simplification of behavior (no need for the option, just working with sharp tags, etc.) offsets the downside of this. 5. There is extra "stuff" in geometry nodes modifier panel - The extra unused panels can be removed one the node panels features make their way to the modifier. - The data-block picker doesn't have to be displayed when adding modifiers from assets, but that is lower priority. ## Technical Info | Sharp Edges | Sharp Face | Normal Domain | Approximate Cost | | ----------- | ---------- | ------------- | ---------------- | | All True | All True | Face | 1.0x | | Any | All True | Face | 1.0x | | All True | Any | Face | 1.0x | | All False | All False | Vertex | 4.0x | | Mixed | Mixed | Face Corner | 10.0x | A function `eAttrDomain Mesh::normal_domain_all_info() const;` gives us this information. We can use its result to optimize normal sampling in many places. Viewport drawing would be one important example. Corner normals are now shared with a `SharedCache`, meaning they don't have to be recomputed just because a mesh is copied. ## Implementation TODOs - [ ] Double check shape key export workflow - [x] Update PR description to be more clear about what parts of the Python API change and to reference the modifier add menu changes - [x] "Unpublish" the "Smooth by Angle" asset in 4.0 - [ ] Test PR with module members - [x] Work on viewport normals simplification option that skips corner normals and custom normals HooglyBoogly/blender#5 - [x] Iterate on the "Smooth by Angle" asset - [x] Potentially not exactly reimplement auto smooth behavior - [x] Potentially add options to give higher level access to different behavior - [x] Reconsider name based on above decisions - [ ] Start implementation of custom normals geometry nodes Related PRs: #108014

image.png

14 KiB

image.png

5.3 KiB

image.png

7.0 KiB

👍 3 ❤️ 4

Hans Goudey changed title from Mesh Smoothing and Normals Design Changes to Mesh Auto Smooth and Normals Design Changes 2021-12-01 20:27:24 +01:00

Zijun Zhou commented 2021-12-02 06:36:43 +01:00

Contributor

Copy Link

Remove shade_smooth and replace it with edge_sharp ? Does it mean all meshes will be smoothed by default and only be unsmoothed by assigning sharps?

Remove `shade_smooth` and replace it with `edge_sharp` ? Does it mean all meshes will be smoothed by default and only be unsmoothed by assigning sharps?

Piotr Adamowicz commented 2021-12-02 11:16:16 +01:00

First-time contributor

Copy Link

Having a geometry node for setting sharps is great, but please retain a simple checkbox and angle slider for this somewhere. Adding modifiers, changing views and editing node trees would make this previously simple task slow, cumbersome, unintuitive and non-discoverable.

Alternatively, make this into a standalone modifier that shares the geometry nodes code.

Edit: Ah. Missed the bit about the modifier in the versioning section. No objections then :)

Having a geometry node for setting sharps is great, but please retain a simple checkbox and angle slider for this somewhere. Adding modifiers, changing views and editing node trees would make this previously simple task slow, cumbersome, unintuitive and non-discoverable. Alternatively, make this into a standalone modifier that shares the geometry nodes code. Edit: Ah. Missed the bit about the modifier in the versioning section. No objections then :)

Jacques Lucke commented 2021-12-02 11:26:31 +01:00

Member

Copy Link

Remove shade_smooth and replace it with edge_sharp ? Does it mean all meshes will be smoothed by default and only be unsmoothed by assigning sharps?

On the user level, no.

> Remove `shade_smooth` and replace it with `edge_sharp` ? Does it mean all meshes will be smoothed by default and only be unsmoothed by assigning sharps? On the user level, no.

Zijun Zhou commented 2021-12-02 11:41:22 +01:00

Contributor

Copy Link

Hmm how does it work then? You said from the user level, does it mean that the user would still think of it as shade smooth, but under the hood it is actually backwards, it is assigning sharp edges rather than assigning smooth flags? I still don't think I get it

Hmm how does it work then? You said from the user level, does it mean that the user would still think of it as shade smooth, but under the hood it is actually backwards, it is assigning sharp edges rather than assigning smooth flags? I still don't think I get it

Jacques Lucke commented 2021-12-02 11:47:55 +01:00

Member

Copy Link

Yes, something like that. We could also invert the edge_sharp flag and store it as edge_smooth internally, that doesn't affect the user though. The main point is to get rid of the smooth/sharp option on faces because it's redundant with the smooth/sharp flag on edges.

Yes, something like that. We could also invert the `edge_sharp` flag and store it as `edge_smooth` internally, that doesn't affect the user though. The main point is to get rid of the smooth/sharp option on faces because it's redundant with the smooth/sharp flag on edges.

Bastien Montagne commented 2022-09-08 10:46:37 +02:00

Owner

Copy Link

I have a few questions or problems with this proposal.

1 - Removing 'smooth face' flag

This will make some behaviors from user perspective not possible anymore. For example, how do you handle 'set face smooth' operation on a flat face sharing an edge with another flat face?

• Currently, setting the face smooth will keep the shared edge sharp, as the other face remains flat.
• If face flag is removed, the shared edge will be marked as smooth? Or something else?

Point being, you cannot say that edge and face flags are fully redundant, they are both combined to define the final sharp vs. smooth state of edges.

2 - Removing autosmooth from mesh and make it a geometry node

While I agree in general with the idea, imho the fact that it enforces generating a separate evaluated mesh for each object is an issue. And I definitely do not see the proposed 'work around' of using object instancing as an acceptable solution here.

Was wondering if having some obdata-level nodetree was ever considered? That would enable some different level of procedural processing of geometry, with some limitation regarding available 'context' info obviously (no object info...).

3 - Split evaluated normals vs. custom normals

I do not really understand what is the issue that is being addressed here, nor what is the proposed solution. Those two data are already very well separated?

• Evaluated split normals are actual 3D vectors, just like 'regular' vertex normals.
• Custom normals are stored as differential values from evaluated normals, applied on top of these when needed. 'When needed' is not only for rendering, they are also required for many geometry processing...

I have a few questions or problems with this proposal. 1 - Removing 'smooth face' flag ------------------------------------ This will make some behaviors from user perspective not possible anymore. For example, how do you handle 'set face smooth' operation on a flat face sharing an edge with another flat face? * Currently, setting the face smooth will keep the shared edge sharp, as the other face remains flat. * If face flag is removed, the shared edge will be marked as smooth? Or something else? Point being, you cannot say that edge and face flags are fully redundant, they are both combined to define the final sharp vs. smooth state of edges. 2 - Removing autosmooth from mesh and make it a geometry node ------------------------------------------------------------------------------- While I agree in general with the idea, imho the fact that it enforces generating a separate evaluated mesh for each object is an issue. And I definitely do not see the proposed 'work around' of using object instancing as an acceptable solution here. Was wondering if having some obdata-level nodetree was ever considered? That would enable some different level of procedural processing of geometry, with some limitation regarding available 'context' info obviously (no object info...). 3 - Split evaluated normals vs. custom normals ------------------------------------------------------- I do not really understand what is the issue that is being addressed here, nor what is the proposed solution. Those two data are already very well separated? * Evaluated split normals are actual 3D vectors, just like 'regular' vertex normals. * Custom normals are stored as differential values from evaluated normals, applied on top of these when needed. 'When needed' is not only for rendering, they are also required for many geometry processing...

Hans Goudey commented 2022-09-13 04:34:43 +02:00

Author

Member

Copy Link

Thanks for the feedback!

Point being, you cannot say that edge and face flags are fully redundant, they are both combined to define the final sharp vs. smooth state of edges.

Good point. I think it's fair to say they are redundant from the perspective of normal calculation, but from the editing perspective the task isn't quite right.
I think this is okay though, we can offset with better tools for creating edge selections if necessary. That specific change might be for the better.
If users just control the data that's used by normal calculation directly, things might be more intuitive.

And I definitely do not see the proposed 'work around' of using object instancing as an acceptable solution here.

That's fair. I guess it would nullify the object-data-sharing design we have now. Though I do think it shows that the design as a whole isn't very scalable.
Object-data level node trees is an interesting idea, but I sort of doubt it would be high enough on the priority list now, so I hope we could find a design that wouldn't depend on that.
I wonder if automatically de-duplicating object evaluation when meshes are shared and modifiers are the same would work.

3 - Split evaluated normals vs. custom normals

I think they are better separated than I thought when I wrote this task, at least internally. So the point is a bit unclear I guess. Here are some more specific suggestions:

• Use the terms "Face corner normals" and "custom normals" in the UI to separate the two concepts and allow for custom normals on other domains.
• Face corner normals should always be used if there are sharp edges.

Also, separate point-- I think it makes sense to allow setting custom normals directly as 3D vectors from a performance perspective, which would make more sense in a procedural context.

Thanks for the feedback! >Point being, you cannot say that edge and face flags are fully redundant, they are both combined to define the final sharp vs. smooth state of edges. Good point. I think it's fair to say they are redundant from the perspective of normal calculation, but from the editing perspective the task isn't quite right. I think this is okay though, we can offset with better tools for creating edge selections if necessary. That specific change might be for the better. If users just control the data that's used by normal calculation directly, things might be more intuitive. >And I definitely do not see the proposed 'work around' of using object instancing as an acceptable solution here. That's fair. I guess it would nullify the object-data-sharing design we have now. Though I do think it shows that the design as a whole isn't very scalable. Object-data level node trees is an interesting idea, but I sort of doubt it would be high enough on the priority list now, so I hope we could find a design that wouldn't depend on that. I wonder if automatically de-duplicating object evaluation when meshes are shared and modifiers are the same would work. >3 - Split evaluated normals vs. custom normals I think they are better separated than I thought when I wrote this task, at least internally. So the point is a bit unclear I guess. Here are some more specific suggestions: - Use the terms "Face corner normals" and "custom normals" in the UI to separate the two concepts and allow for custom normals on other domains. - Face corner normals should _always_ be used if there are sharp edges. Also, separate point-- I think it makes sense to allow setting custom normals directly as 3D vectors from a performance perspective, which would make more sense in a procedural context.

aVersionOfReality commented 2022-09-13 05:13:07 +02:00

First-time contributor

Copy Link

I do not understand all the details of the discussion, but as someone who is already working a lot with Normals in Geometry Nodes, I can attest that it would be very convenient if we had full access to Normals of each Domain, and Custom Normals, and the ability to properly set them from within GeoNodes.

I am giving this feedback to show that there is interest in these features among some users (Stylized/Toon/NPR artists). I know that these sorts of features would not be used in many workflows, but I hope we'll still get these options.

Currently, I am doing all sorts of extra/redundant edge splitting and interpolation to achieve within GeoNodes things that are standard outside of it. The lack of access to Custom Normals has also been a major blockage. If we also had UV Tangents available in GeoNodes for Normal Mapping, we would have full flexibility.

I do not understand all the details of the discussion, but as someone who is [already working a lot with Normals ](http://www.aversionofreality.com/blog/2022/4/21/custom-normals-workflow) in Geometry Nodes, I can attest that it would be very convenient if we had full access to Normals of each Domain, and Custom Normals, and the ability to properly set them from within GeoNodes. I am giving this feedback to show that there is interest in these features among some users (Stylized/Toon/NPR artists). I know that these sorts of features would not be used in many workflows, but I hope we'll still get these options. Currently, I am doing all sorts of extra/redundant edge splitting and interpolation to achieve within GeoNodes things that are standard outside of it. The lack of access to Custom Normals has also been a major blockage. If we also had UV Tangents available in GeoNodes for Normal Mapping, we would have full flexibility.

👍 1

Iliya Katueshenock commented 2022-09-13 10:49:21 +02:00

Member

Copy Link

In #93551#1416105, @ColinBarton wrote:
access to Normals of each Domain

I'm not sure how to understand normals for all types of domains.
Since the render object is a polygon, it is logical that it is the only one that has a normal.
But since we won't have enough vertices for complex normals for several polygons, it is logical that we are talking about a face corner.
I'm not sure how edge normals should blend correctly for face corners as they do for vertices.

> In #93551#1416105, @ColinBarton wrote: > access to Normals of each Domain I'm not sure how to understand normals for all types of domains. Since the render object is a polygon, it is logical that it is the only one that has a normal. But since we won't have enough vertices for complex normals for several polygons, it is logical that we are talking about a face corner. I'm not sure how edge normals should blend correctly for face corners as they do for vertices.

aVersionOfReality commented 2022-09-13 18:36:00 +02:00

First-time contributor

Copy Link

In #93551#1416229, @mod_moder wrote:

In #93551#1416105, @ColinBarton wrote:
access to Normals of each Domain

I'm not sure how to understand normals for all types of domains.
Since the render object is a polygon, it is logical that it is the only one that has a normal.
But since we won't have enough vertices for complex normals for several polygons, it is logical that we are talking about a face corner.
I'm not sure how edge normals should blend correctly for face corners as they do for vertices.

Ah yes, I mean Face, Vertex, and Face Corner (which all end up as Face Corner). I don't think much can be done with Edges Normals except perhaps some curvature stuff.

> In #93551#1416229, @mod_moder wrote: >> In #93551#1416105, @ColinBarton wrote: >> access to Normals of each Domain > I'm not sure how to understand normals for all types of domains. > Since the render object is a polygon, it is logical that it is the only one that has a normal. > But since we won't have enough vertices for complex normals for several polygons, it is logical that we are talking about a face corner. > I'm not sure how edge normals should blend correctly for face corners as they do for vertices. Ah yes, I mean Face, Vertex, and Face Corner (which all end up as Face Corner). I don't think much can be done with Edges Normals except perhaps some curvature stuff.

James Stout commented 2022-11-19 02:12:46 +01:00

First-time contributor

Copy Link

Been trying to make game art tree meshes with a GeoNodes network. Surprisingly, it's been very simple, up until the point at which I actually need to transfer the normal information to the final mesh. Being able to set & bake down custom normals per Face Corner / Vertex would be excellent. I've been able to view exactly the normals I want to achieve with the viewer node in the 3.4 beta, but I have no way to actually bake these down to face corner data.

From the dummy artists to the folks who implement this on the code side, ty for working on this. GeoNodes are immensely cool and starting to finally come into their own with regards to generating game ready assets.

Been trying to make game art tree meshes with a GeoNodes network. Surprisingly, it's been very simple, up until the point at which I actually need to transfer the normal information to the final mesh. Being able to set & bake down custom normals per Face Corner / Vertex would be excellent. I've been able to view exactly the normals I want to achieve with the viewer node in the 3.4 beta, but I have no way to actually bake these down to face corner data. From the dummy artists to the folks who implement this on the code side, ty for working on this. GeoNodes are immensely cool and starting to finally come into their own with regards to generating game ready assets.  

👍 2

Hans Goudey added this to the 4.0 milestone 2023-03-04 19:03:59 +01:00

Hans Goudey added this to the Nodes & Physics project 2023-03-04 19:04:23 +01:00

Hans Goudey added

Type

To Do

and removed

Type

Design

labels 2023-03-04 19:06:42 +01:00

Thomas Dinges referenced this issue 2023-03-07 11:07:33 +01:00

Breaking changes for 4.0 #105523

Wahid commented 2023-04-03 00:14:48 +02:00

First-time contributor

Copy Link

The most important part I can control if the edge to be "Hard" or "Soft".
this will make life easier.
adding sharp edge and soft edge will be great step.

The most important part I can control if the edge to be "Hard" or "Soft". this will make life easier. adding sharp edge and soft edge will be great step.

Andres Stephens commented 2023-04-26 17:40:50 +02:00

First-time contributor

Copy Link

This solution may solve this task: #107376

This solution may solve this task: https://projects.blender.org/blender/blender/issues/107376

Hans Goudey referenced this issue 2023-04-26 18:10:34 +02:00

Geometry Nodes - Realize Instances looses original collection meshes' autosmooth normal data #107376

Hans Goudey commented 2023-04-26 18:12:05 +02:00

Author

Member

Copy Link

I started to work on this here: https://projects.blender.org/HooglyBoogly/blender/src/branch/refactor-mesh-corner-normals-lazy

That branch contains most of the changes except for the ability to set custom normals in geometry nodes.

I started to work on this here: https://projects.blender.org/HooglyBoogly/blender/src/branch/refactor-mesh-corner-normals-lazy That branch contains most of the changes except for the ability to set custom normals in geometry nodes.

🚀 6

Hans Goudey referenced this issue 2023-05-02 14:45:37 +02:00

Breaking Mesh API changes for 4.0 #100153

Hans Goudey referenced this issue 2023-05-17 16:41:42 +02:00

Mesh: Replace auto smooth with node group #108014

Hans Goudey changed title from Mesh Auto Smooth and Normals Design Changes to Mesh Normals and Auto Smooth in 4.0 2023-06-12 22:36:48 +02:00

Hans Goudey commented 2023-06-21 22:09:17 +02:00

Author

Member

Copy Link

While I agree in general with the idea, imho the fact that it enforces generating a separate evaluated mesh for each object is an issue. And I definitely do not see the proposed 'work around' of using object instancing as an acceptable solution here.

The workaround is a bit simpler actually, the new modifier can be applied to the mesh (or the same thing can be done with an operator in edit mode). For non-deformed meshes, the results will be the same. For deformed meshes, they would have had a separate evaluated mesh per object anyway. We can't really do this automatically though.

>While I agree in general with the idea, imho the fact that it enforces generating a separate evaluated mesh for each object is an issue. And I definitely do not see the proposed 'work around' of using object instancing as an acceptable solution here. The workaround is a bit simpler actually, the new modifier can be applied to the mesh (or the same thing can be done with an operator in edit mode). For non-deformed meshes, the results will be the same. For deformed meshes, they would have had a separate evaluated mesh per object anyway. We can't really do this automatically though.

Brecht Van Lommel commented 2023-06-22 10:51:38 +02:00

Owner

Copy Link

Some feedback on the design:

• I do not think an edit mode operator for autosmooth should add a modifier. It's inconsistent with other edit mode operators, they apply results to the mesh immediately and I see no good reason to deviate from that here. Autosmooth as a modifier should mostly be used for procedural modeling, and for that they can just be added the same way as other geometry nodes.
• I'm not sure about replacing native functionality with a node group like this given the current geometry nodes modifier UI. For someone who wants to use this like any other modifier, the node group selection, output attributes and internal dependencies are irrelevant. Plus it does not appear in the modifier add menu, and there is no dedicated icon. Personally I would have renamed and extended the Edge Split modifier with this functionality instead. I don't know that it has to be a blocker, but also think it's not great if we start moving this direction in general without a UI that can integrate assets at the same level as native modifiers.
  

Some feedback on the design: * I do not think an edit mode operator for autosmooth should add a modifier. It's inconsistent with other edit mode operators, they apply results to the mesh immediately and I see no good reason to deviate from that here. Autosmooth as a modifier should mostly be used for procedural modeling, and for that they can just be added the same way as other geometry nodes. * I'm not sure about replacing native functionality with a node group like this given the current geometry nodes modifier UI. For someone who wants to use this like any other modifier, the node group selection, output attributes and internal dependencies are irrelevant. Plus it does not appear in the modifier add menu, and there is no dedicated icon. Personally I would have renamed and extended the Edge Split modifier with this functionality instead. I don't know that it has to be a blocker, but also think it's not great if we start moving this direction in general without a UI that can integrate assets at the same level as native modifiers. 

❤️ 2

Bastien Montagne commented 2023-06-22 13:12:20 +02:00

Owner

Copy Link

While I agree in general with the idea, imho the fact that it enforces generating a separate evaluated mesh for each object is an issue. And I definitely do not see the proposed 'work around' of using object instancing as an acceptable solution here.

The workaround is a bit simpler actually, the new modifier can be applied to the mesh (or the same thing can be done with an operator in edit mode). For non-deformed meshes, the results will be the same. For deformed meshes, they would have had a separate evaluated mesh per object anyway. We can't really do this automatically though.

Applying a modifier is final and definitive, you cannot edit the values anymore. You would need to add the modifier again, and apply it again, every time you need to change the settings. So I don't think this properly replaces the current autosmooth feature either.

The current autosmooth behaves like an ObData-level modifier/geometrynode tree. Moving it to Object level is anything but a trivial decision. I would like to see a more strong compelling reason than those exposed so far for this change.

On a technical note, adding or removing modifiers (like any other object-mode-level operation) should be avoided at all cost in Edit modes, this is not well supported by undo system currently.

> >While I agree in general with the idea, imho the fact that it enforces generating a separate evaluated mesh for each object is an issue. And I definitely do not see the proposed 'work around' of using object instancing as an acceptable solution here. > > The workaround is a bit simpler actually, the new modifier can be applied to the mesh (or the same thing can be done with an operator in edit mode). For non-deformed meshes, the results will be the same. For deformed meshes, they would have had a separate evaluated mesh per object anyway. We can't really do this automatically though. Applying a modifier is final and definitive, you cannot edit the values anymore. You would need to add the modifier again, and apply it again, every time you need to change the settings. So I don't think this properly replaces the current autosmooth feature either. The current autosmooth behaves like an ObData-level modifier/geometrynode tree. Moving it to Object level is anything but a trivial decision. I would like to see a more strong compelling reason than those exposed so far for this change. On a technical note, adding or removing modifiers (like any other object-mode-level operation) should be avoided at all cost in Edit modes, this is not well supported by undo system currently.

Hans Goudey commented 2023-06-23 19:37:28 +02:00

Author

Member

Copy Link

I do not think an edit mode operator for autosmooth should add a modifier.

Sorry that was unclear, I'm not proposing that we do that. The operator in edit mode just works as it does now, just changing the sharp edge data directly.

For someone who wants to use this like any other modifier, the node group selection, output attributes and internal dependencies are irrelevant

We'll most likely be able to hide these panels in 4.0, luckily, as part of the work on node panels. As part of more general "assets as modifiers" work, we could consider hiding the node group selector by default, just like we do for nodes. I don't see this as blocking though.

it's not great if we start moving this direction in general without a UI that can integrate assets at the same level as native modifiers.

Yes, I agree about this. Ways to add node group assets directly as modifiers are planned, but I don't think we'll have time to get to it for 4.0. Again, not blocking for this specific change IMO, but it does make it a bit more urgent.

Personally I would have renamed and extended the Edge Split modifier with this functionality instead

I get your point, but in the longer term I think the consistency of having features built out of visible, editable node group assets will be very important. Users can tweaking, and learn from builtin groups. And giving a generic interface for user-created and builtin features is a huge opportunity for Blender as a whole.

The current autosmooth behaves like an ObData-level modifier/geometrynode tree. Moving it to Object level is anything but a trivial decision.

The point is to make the behavior more generic, so it becomes more predictable, more performant, and more consistent with the rest of Blender and user created tools. The fact is, we don't have object-data level modifiers/nodes, and I don't think we will any time soon. Actions are applied to geometry on the object-level, that's just how things work.

Also, the benefit of the old "procedural" auto smooth behavior compared to running a static operator is questionable. Users may run the operator to set sharp edges more often, or computation might be duplicated between objects before the modifiers are applied, but I see those downsides as far outweighed by unified, consistent behavior that actually mirrors what's happening internally.

>I do not think an edit mode operator for autosmooth should add a modifier. Sorry that was unclear, I'm not proposing that we do that. The operator in edit mode just works as it does now, just changing the sharp edge data directly. >For someone who wants to use this like any other modifier, the node group selection, output attributes and internal dependencies are irrelevant We'll most likely be able to hide these panels in 4.0, luckily, as part of the work on node panels. As part of more general "assets as modifiers" work, we could consider hiding the node group selector by default, just like we do for nodes. I don't see this as blocking though. >it's not great if we start moving this direction in general without a UI that can integrate assets at the same level as native modifiers. Yes, I agree about this. Ways to add node group assets directly as modifiers are planned, but I don't think we'll have time to get to it for 4.0. Again, not blocking for this specific change IMO, but it does make it a bit more urgent. >Personally I would have renamed and extended the Edge Split modifier with this functionality instead I get your point, but in the longer term I think the consistency of having features built out of visible, editable node group assets will be very important. Users can tweaking, and learn from builtin groups. And giving a generic interface for user-created and builtin features is a huge opportunity for Blender as a whole. >The current autosmooth behaves like an ObData-level modifier/geometrynode tree. Moving it to Object level is anything but a trivial decision. The point is to make the behavior more generic, so it becomes more predictable, more performant, and more consistent with the rest of Blender and user created tools. The fact is, we don't have object-data level modifiers/nodes, and I don't think we will any time soon. _Actions_ are applied to geometry on the object-level, that's just how things work. Also, the benefit of the old "procedural" auto smooth behavior compared to running a static operator is questionable. Users may run the operator to set sharp edges more often, or computation might be duplicated between objects before the modifiers are applied, but I see those downsides as far outweighed by unified, consistent behavior that actually mirrors what's happening internally.

Brecht Van Lommel commented 2023-06-23 19:51:34 +02:00

Owner

Copy Link

I get your point, but in the longer term I think the consistency of having features built out of visible, editable node group assets will be very important. Users can tweaking, and learn from builtin groups. And giving a generic interface for user-created and builtin features is a huge opportunity for Blender as a whole.

I don't mind it being built on geometry nodes by itself. My main concern is that users will ask how to do the equivalent of the old autosmooth in 4.0, and if the answer is that they have to manually create a geometry nodes modifier and add an autosmooth node in a node editor, that's not very satisfactory.

If we can integrate bundled node group assets into the modifier add menu somehow it would be fine, but I'm not sure if something like that will be in 4.0?

> I get your point, but in the longer term I think the consistency of having features built out of visible, editable node group assets will be very important. Users can tweaking, and learn from builtin groups. And giving a generic interface for user-created and builtin features is a huge opportunity for Blender as a whole. I don't mind it being built on geometry nodes by itself. My main concern is that users will ask how to do the equivalent of the old autosmooth in 4.0, and if the answer is that they have to manually create a geometry nodes modifier and add an autosmooth node in a node editor, that's not very satisfactory. If we can integrate bundled node group assets into the modifier add menu somehow it would be fine, but I'm not sure if something like that will be in 4.0?

Hans Goudey commented 2023-06-23 20:01:08 +02:00

Author

Member

Copy Link

My idea was to include an operator in the Mesh menu in object mode called "Add Auto Smooth" which would add the modifier with the specified angle. That would be an alternative to the operator editing the "sharp_edge" attribute directly. It could also be part of the existing "Auto Smooth" operator, as an "As Modifier" option. That's the one thing I didn't get to implement in the branch yet though.

If we can integrate bundled node group assets into the modifier add menu somehow it would be fine, but I'm not sure if something like that will be in 4.0?

I'd love to say it would be in 4.0 but I don't think that's realistic unless we skip working on something like node tools. That operator setup I mentioned could be replaced when assets and the add modifier menu are integrated though.

My idea was to include an operator in the Mesh menu in object mode called "Add Auto Smooth" which would add the modifier with the specified angle. That would be an alternative to the operator editing the "sharp_edge" attribute directly. It could also be part of the existing "Auto Smooth" operator, as an "As Modifier" option. That's the one thing I didn't get to implement in the branch yet though. >If we can integrate bundled node group assets into the modifier add menu somehow it would be fine, but I'm not sure if something like that will be in 4.0? I'd love to say it would be in 4.0 but I don't think that's realistic unless we skip working on something like node tools. That operator setup I mentioned could be replaced when assets and the add modifier menu are integrated though.

Paul Kotelevets commented 2023-06-23 21:25:36 +02:00

First-time contributor

Copy Link

I agree with Brecht.
Autosmooth is often massively applied over a huge number of an objects simultaneosly, autosmooth as modifier is a concept which is hard to handle and control its distribution.
For example, eliminating it for the objects that also has different modifiers stacks will be problematic.

I agree with Brecht. Autosmooth is often massively applied over a huge number of an objects simultaneosly, autosmooth as modifier is a concept which is hard to handle and control its distribution. For example, eliminating it for the objects that also has different modifiers stacks will be problematic.

Hans Goudey referenced this issue 2023-07-26 14:33:54 +02:00

Fix #109583: Avoid non-threadsafe writing to custom normals data #110478

Hans Goudey referenced this issue from a commit 2023-07-26 17:04:21 +02:00

Fix #109583: Avoid non-threadsafe writing to custom normals data

Hans Goudey referenced this issue from a commit 2023-08-04 20:04:34 +02:00

Cleanup: Small improvements to Hydra mesh and curves export

Jacob-Costen commented 2023-08-19 11:36:06 +02:00

First-time contributor

Copy Link

For what it's worth, here's my two cents. Having control over custom normals from geometry nodes would be very useful, however, as someone who does quite a bit of hard-surface work and uses Auto Smooth, having to manually add an asset/GeoNodes modifier would be kind of a massive pain. I agree with Brecht that just adding an Edit/Object mode operator which automatically appends and applies an AutoSmooth nodegroup feels like a workaround in order to prevent the feature from being unwieldy. As Brecht says, anyone who used this feature will say 'well how do I do it now?' and be a bit sad upon opening older files to find that Auto Smoothed objects are all just smooth (or flat) now and need extra work. I mean I was asking myself what the alternative method would be halfway through reading this proposal.
The other point I wanted to mention was the 'Add Auto Smooth' idea of an operator which does the smooth shading and applies it there and then. Almost every use I've found for the Auto Smooth option it's a procedural, non-destructive workflow. I.e. you set that flag, and then you can just start work modelling and your mesh will appear smoothed appropriately as you work, so you can see what it looks like in real time and inform creative (as well as technical) decisions. Based on the fact that it's literally called Auto Smooth, I'd strongly be on the side of non-destructive being the default behaviour, and 'applying' those edge and face sharpness flags to the mesh destructively as a final step: case in point, for a lot of hard surface work the very final step is to apply split normals data, then go through and split/mark sharp any other edges you want finer control over.

The only solution I can think of would be to more closely integrate asset GeoNode modifiers with built-in modifiers, for instance by splitting the 'Add Modifier' selection pane to have an extra column for GeoNode assets from libraries (that way Auto Smooth is still one click away, no going to the asset browser and appending, then going back to modifiers, etc etc), or to break that 'Add Modifier' dropdown button in half, and have the right side bring up a similarly formatted pane which lists GeoNode assets which are available.
However, this is rather a bigger proposal (though I think one which would be very useful beyond just fixing Auto Smooth).

For what it's worth, here's my two cents. Having control over custom normals from geometry nodes would be very useful, however, as someone who does quite a bit of hard-surface work and uses Auto Smooth, having to manually add an asset/GeoNodes modifier would be kind of a massive pain. I agree with Brecht that just adding an Edit/Object mode operator which automatically appends and applies an AutoSmooth nodegroup feels like a workaround in order to prevent the feature from being unwieldy. As Brecht says, anyone who used this feature will say 'well how do I do it now?' and be a bit sad upon opening older files to find that Auto Smoothed objects are all just smooth (or flat) now and need extra work. I mean I was asking myself what the alternative method would be halfway through reading this proposal. The other point I wanted to mention was the 'Add Auto Smooth' idea of an operator which does the smooth shading and applies it there and then. Almost every use I've found for the Auto Smooth option it's a procedural, non-destructive workflow. I.e. you set that flag, and then you can just start work modelling and your mesh will appear smoothed appropriately as you work, so you can see what it looks like in real time and inform creative (as well as technical) decisions. Based on the fact that it's literally called Auto Smooth, I'd strongly be on the side of non-destructive being the default behaviour, and 'applying' those edge and face sharpness flags to the mesh destructively as a final step: case in point, for a lot of hard surface work the very final step is to apply split normals data, then go through and split/mark sharp any other edges you want finer control over. The only solution I can think of would be to more closely integrate asset GeoNode modifiers with built-in modifiers, for instance by splitting the 'Add Modifier' selection pane to have an extra column for GeoNode assets from libraries (that way Auto Smooth is still one click away, no going to the asset browser and appending, then going back to modifiers, etc etc), or to break that 'Add Modifier' dropdown button in half, and have the right side bring up a similarly formatted pane which lists GeoNode assets which are available. However, this is rather a bigger proposal (though I think one which would be very useful beyond just fixing Auto Smooth).

Hans Goudey commented 2023-08-19 22:12:47 +02:00

Author

Member

Copy Link

upon opening older files to find that Auto Smoothed objects are all just smooth (or flat) now and need extra work

To be clear, the node group is added by versioning code. The results of existing files or meshes do not change.

The only solution I can think of would be to more closely integrate asset GeoNode modifiers with built-in modifiers

Yes, I agree with this. Considering the points above, it probably makes sense to do this for 4.0. The add modifier menu should change into a search menu, and geometry node group assets can have an "Is Modifier" option to make them show in the add menu. Ideally we can do this in a separate step from the initial change though, we'd just need to agree on a design.

I still think an operator to add or remove the modifier asset would be useful though. Like you said, that could be the default behavior-- that sort of thing can be easily changed during a polishing phase.

>upon opening older files to find that Auto Smoothed objects are all just smooth (or flat) now and need extra work To be clear, the node group is added by versioning code. The results of existing files or meshes do not change. >The only solution I can think of would be to more closely integrate asset GeoNode modifiers with built-in modifiers Yes, I agree with this. Considering the points above, it probably makes sense to do this for 4.0. The add modifier menu should change into a search menu, and geometry node group assets can have an "Is Modifier" option to make them show in the add menu. Ideally we can do this in a separate step from the initial change though, we'd just need to agree on a design. I still think an operator to add or remove the modifier asset would be useful though. Like you said, that could be the default behavior-- that sort of thing can be easily changed during a polishing phase.

👍 1

Mysteryem commented 2023-08-22 01:05:14 +02:00

Member

Copy Link

FBX, and possibly other exporters, use create_normals_split() and then access the corner normals. This gets the normals taking into account use_auto_smooth and auto_smooth_angle (and faces/edges marked as sharp and custom normals).

With the change to move Auto Smooth to a Geometry Nodes modifier, as far as I can tell, to access the normals after the effect of Auto Smooth would require either applying the Geometry Nodes modifier or accessing the normals from the evaluated mesh.

A possible problem I see currently is that FBX supports exporting shape keys, which is done by using the mesh directly without evaluating it. Loading a .blend into a newer Blender version that replaces use_auto_smooth with a Geometry nodes modifier through versioning code would currently result in exporting normals without Auto Smooth taken into account compared to exporting that same .blend in an older Blender version.

The FBX exporter has an option for applying modifiers, but that is done by using the evaluated mesh, which means shape keys can't be exported.

FBX, and possibly other exporters, use `create_normals_split()` and then access the corner normals. This gets the normals taking into account `use_auto_smooth` and `auto_smooth_angle` (and faces/edges marked as sharp and custom normals). With the change to move Auto Smooth to a Geometry Nodes modifier, as far as I can tell, to access the normals after the effect of Auto Smooth would require either applying the Geometry Nodes modifier or accessing the normals from the evaluated mesh. A possible problem I see currently is that FBX supports exporting shape keys, which is done by using the mesh directly without evaluating it. Loading a .blend into a newer Blender version that replaces `use_auto_smooth` with a Geometry nodes modifier through versioning code would currently result in exporting normals without Auto Smooth taken into account compared to exporting that same .blend in an older Blender version. The FBX exporter has an option for applying modifiers, but that is done by using the evaluated mesh, which means shape keys can't be exported.

👍 1

Hans Goudey commented 2023-08-22 22:03:38 +02:00

Author

Member

Copy Link

Thanks for bringing that up. In some cases the set_sharp_from_angle Mesh API function might be helpful in some situations. But I'd imagine that the exporter would want to detect the modifier and node group to find the angle. That seems not ideal from an implementation perspective, but as Blender adds more node-based features in the future that will probably only happen more.

Thanks for bringing that up. In some cases the `set_sharp_from_angle` Mesh API function might be helpful in some situations. But I'd imagine that the exporter would want to detect the modifier and node group to find the angle. That seems not ideal from an implementation perspective, but as Blender adds more node-based features in the future that will probably only happen more.

Hans Goudey commented 2023-09-01 15:28:51 +02:00

Author

Member

Copy Link

I added some common concerns / a FAQ to the design task.

I added some common concerns / a FAQ to the design task.

👍 1

Julien DUROURE commented 2023-09-01 15:56:54 +02:00

Member

Copy Link

Hello,
First question: Is it only for "auto smooth", or also for "Custom Split Normals data" (that requires to have auto smooth ON) ?
I can see impact on glTF importer in case we can't create some normal layer anymore.

Like FBX exporter, for glTF, I not sure how to manage exporter if we have only the modifier instead of autosmooth. Applying modifier to get the normal data will prevent exporting shapekeys.

Hello, First question: Is it only for "auto smooth", or also for "Custom Split Normals data" (that requires to have auto smooth ON) ? I can see impact on glTF importer in case we can't create some normal layer anymore. Like FBX exporter, for glTF, I not sure how to manage exporter if we have only the modifier instead of autosmooth. Applying modifier to get the normal data will prevent exporting shapekeys.

Hans Goudey commented 2023-09-01 16:45:55 +02:00

Author

Member

Copy Link

Hi! For the first question, this only affects auto smooth. Using custom normals gets a bit simpler actually, since it doesn't require turning on an "Auto Smooth" option anymore.

Second, could you clarify why applying the modifier would prevent exporting shape keys? Making a local copy of the mesh and setting sharp edges based on the same angle as the modifier should work too.

Hi! For the first question, this only affects auto smooth. Using custom normals gets a bit simpler actually, since it doesn't require turning on an "Auto Smooth" option anymore. Second, could you clarify why applying the modifier would prevent exporting shape keys? Making a local copy of the mesh and setting sharp edges based on the same angle as the modifier should work too.

👍 1

Piotr Adamowicz commented 2023-09-02 15:28:25 +02:00

First-time contributor

Copy Link

Using custom normals gets a bit simpler actually, since it doesn't require turning on an "Auto Smooth" option anymore.

If it doesn't require it anymore, how can you preview the smoothed mesh normals without deleting the custom normals layer? It's kind of important to be able to do this when working with, say, models from CAD apps because it allows you to easily see problems with the imported mesh.

> Using custom normals gets a bit simpler actually, since it doesn't require turning on an "Auto Smooth" option anymore. If it doesn't require it anymore, how can you preview the smoothed mesh normals without deleting the custom normals layer? It's kind of important to be able to do this when working with, say, models from CAD apps because it allows you to easily see problems with the imported mesh.

Hans Goudey commented 2023-09-03 05:15:39 +02:00

Author

Member

Copy Link

I think that would be possible once custom normals (the ability to set and clear them) is exposed to geometry nodes, which is the next step.

I think that would be possible once custom normals (the ability to set and clear them) is exposed to geometry nodes, which is the next step.

Paul Szajner commented 2023-09-03 20:10:23 +02:00

First-time contributor

Copy Link

Second, could you clarify why applying the modifier would prevent exporting shape keys?

I think he meant that in order to export to FBX or GLTF modifiers needs to be applied, however, if an object has shape keys you can't apply modifiers anymore.

I guess it's more a modifier/shape keys issue ...

> Second, could you clarify why applying the modifier would prevent exporting shape keys? I think he meant that in order to export to FBX or GLTF modifiers needs to be applied, however, if an object has shape keys you can't apply modifiers anymore.  I guess it's more a modifier/shape keys issue ...

image.png

143 KiB

Hans Goudey referenced this issue 2023-09-06 21:45:13 +02:00

Fix #109583: Avoid non-threadsafe writing to custom normals data #112055

Hans Goudey referenced this issue from a commit 2023-09-06 22:19:17 +02:00

Fix #109583: Avoid non-threadsafe writing to custom normals data

Hans Goudey modified the milestone from 4.0 to 4.1 2023-09-07 23:16:05 +02:00

Hans Goudey commented 2023-09-07 23:28:04 +02:00

Author

Member

Copy Link

Bastien, Campbell, and I just met about the state of this task/PR, we agreed to move this from 4.0 to 4.1.

In the extra 2.5 weeks I'll cover the TODO items mentioned in this task above.

Pros of 4.0

• Group breaking mesh changes together in one release
• Keep breaking changes in major releases
• Avoid maintenance of the patch in the meantime
• Use the modifier add menu asset integration in the first release it's available
• (obvious) release the feature and performance improvements sooner
• Fix #107500 now rather than later

Pros of 4.1

• Be more conservative with the Bcon schedule
• More time for feedback from modeling module members
• Group the change with the custom normals geometry nodes, which helps to motivate the breaking changes
• Add time to work on simplify option to help "disable" custom normals
• More time to validate IO workflow
• Only a 3 week delay if this is committed at the start of Bcon1

Bastien, Campbell, and I just met about the state of this task/PR, we agreed to move this from 4.0 to 4.1. In the extra 2.5 weeks I'll cover the TODO items mentioned in this task above. **Pros of 4.0** - Group breaking mesh changes together in one release - Keep breaking changes in major releases - Avoid maintenance of the patch in the meantime - Use the modifier add menu asset integration in the first release it's available - (obvious) release the feature and performance improvements sooner - Fix #107500 now rather than later **Pros of 4.1** - Be more conservative with the Bcon schedule - More time for feedback from modeling module members - Group the change with the custom normals geometry nodes, which helps to motivate the breaking changes - Add time to work on simplify option to help "disable" custom normals - More time to validate IO workflow - Only a 3 week delay if this is committed at the start of Bcon1

👍 3 🚀 1

Hans Goudey changed title from Mesh Normals and Auto Smooth in 4.0 to Mesh Normals and Auto Smooth in 4.1 2023-09-07 23:28:42 +02:00

Jacob-Costen commented 2023-09-08 02:26:52 +02:00

First-time contributor

Copy Link

sounds like you’ve got this under control. looking forward to when we see this in 4.1!

sounds like you’ve got this under control. looking forward to when we see this in 4.1!

❤️ 1

Bastien Montagne commented 2023-09-08 10:20:44 +02:00

Owner

Copy Link

Thanks for this great summary of the meeting Hans! Would suggest to move the bullet points in the task itself (under e.g. a TODO for 4.1 merge section or so)? Easier to keep track of these then.

Thanks for this great summary of the meeting Hans! Would suggest to move the bullet points in the task itself (under e.g. a `TODO for 4.1 merge` section or so)? Easier to keep track of these then.

👍 1

Julien DUROURE commented 2023-09-08 10:23:21 +02:00

Member

Copy Link

Thanks for the status.
Feel free to contact me for any question regarding glTF I/O

Thanks for the status. Feel free to contact me for any question regarding glTF I/O

Hans Goudey referenced this issue from a commit 2023-10-20 16:54:20 +02:00

Mesh: Replace auto smooth with node group

David Black commented 2023-11-05 16:42:52 +01:00

First-time contributor

Copy Link

Hi @HooglyBoogly,

Feedback following tests...

When opening older files, wonder if informing people Auto smooth has been renamed toSmooth by angle, and keeping just one modifier is simpler?

Rationale:

• Both context menu and modifier use the same Smooth by angle name.
• Can be confusing since there's no Auto smooth modifier when searching the modifiers list.
• Smooth by angle modifier has the extra useful 'Ignore Sharpness' feature, plus layout appears simpler and cleaner.

In case helpful, noticed some differences when opening older files, appears if there's a WeightedNormal modifier, Auto smooth / Smooth by angle modifiers need to be automatically added just before it, or not added at all?

Kind regards.

Hi @HooglyBoogly, Feedback following tests... When opening older files, wonder if informing people `Auto smooth` has been renamed to`Smooth by angle`, and keeping just one modifier is simpler? Rationale: - Both context menu and modifier use the same `Smooth by angle` name. - Can be confusing since there's no `Auto smooth` modifier when searching the modifiers list. - `Smooth by angle` modifier has the extra useful 'Ignore Sharpness' feature, plus layout appears simpler and cleaner. In case helpful, noticed some differences when opening older files, appears if there's a `WeightedNormal` modifier, `Auto smooth` / `Smooth by angle` modifiers need to be automatically added just before it, or not added at all? Kind regards.

👍 1

michael campbell commented 2023-11-07 18:01:30 +01:00

First-time contributor

Copy Link

Would it be possible to simplify this further by just have a single shading normals attribute that's updated whenever the connected vertices are moved. Adding a 'lock_shading_normals' attribute per vertex would indicate the shading normals should be the calculated normals + offset, and unlocked = calculated smoothed normals.

Marking a face or edge as sharp, would just modify the shading normals and mark them as locked.

It's a bit confusing now for example if you have a smooth by angle modifier followed by a weighted normals modifier, because when you apply them, you end up with a combination of edges automatically marked as sharp for you in edit mode, plus custom split normals get created when applying the weighted normal modifier. Would be far simpler for both to just modify a single shading normals attribute and not generate sharp_edge or sharp_face data.

I think the sharp_edge and sharp_face attributes could probably be ditched and just calculate the overlays and 'is edge smooth'/'is face smooth' from the single shading normals attribute of connected vertices. Maybe store them in a non user facing variable to avoid recalculating unless modified.

for performance, don't store the attributes in the actual mesh, attach a separate table for each attribute to the mesh, then you don't have to traverse the entire mesh when reading an attribute that might only be set to something meaningful for a few verts/faces/edges, row 1 = default to be used if a record isn't created for a certain element index. This will also save a lot of memory on large models, where only a few indices have the attribute set to something other than default.

Would it be possible to simplify this further by just have a single shading normals attribute that's updated whenever the connected vertices are moved. Adding a 'lock_shading_normals' attribute per vertex would indicate the shading normals should be the calculated normals + offset, and unlocked = calculated smoothed normals. Marking a face or edge as sharp, would just modify the shading normals and mark them as locked. It's a bit confusing now for example if you have a smooth by angle modifier followed by a weighted normals modifier, because when you apply them, you end up with a combination of edges automatically marked as sharp for you in edit mode, plus custom split normals get created when applying the weighted normal modifier. Would be far simpler for both to just modify a single shading normals attribute and not generate sharp_edge or sharp_face data. I think the sharp_edge and sharp_face attributes could probably be ditched and just calculate the overlays and 'is edge smooth'/'is face smooth' from the single shading normals attribute of connected vertices. Maybe store them in a non user facing variable to avoid recalculating unless modified. for performance, don't store the attributes in the actual mesh, attach a separate table for each attribute to the mesh, then you don't have to traverse the entire mesh when reading an attribute that might only be set to something meaningful for a few verts/faces/edges, row 1 = default to be used if a record isn't created for a certain element index. This will also save a lot of memory on large models, where only a few indices have the attribute set to something other than default.

CarloAndreacchio commented 2023-11-08 01:02:36 +01:00

First-time contributor

Copy Link

I have some concerns that this is listed as a breaking change for 4.0, but there is no solution for breaking instancing for those objects.

For production scenes which are geometry heavy, and rely on instancing, this would be a major issue.

Has there been any proposal on fixing this issue?

I have some concerns that this is listed as a breaking change for 4.0, but there is no solution for breaking instancing for those objects. For production scenes which are geometry heavy, and rely on instancing, this would be a major issue. Has there been any proposal on fixing this issue?

michael campbell commented 2023-11-09 15:56:39 +01:00

First-time contributor

Copy Link

With the current design, I think the smooth by angle option in the context menu should create a modifier rather than adding sharp edges, because that will result in the same expected behaviour found in previous blender versions, where the shading would adhere to the selected angle when modifying the mesh. Maybe have 2 options in the context menu: shade by angle (current shape), and shade by angle (continual update). Or maybe better still the context menu could have: 'add shade by angle modifier' and 'generate sharp edges from angle'.

The sharps should only be created when modelling is complete and the user chooses to apply the modifier (although having a single shading normals attribute that gets modified instead of creating sharp edges would still be my preference).

With the current design, I think the smooth by angle option in the context menu should create a modifier rather than adding sharp edges, because that will result in the same expected behaviour found in previous blender versions, where the shading would adhere to the selected angle when modifying the mesh. Maybe have 2 options in the context menu: shade by angle (current shape), and shade by angle (continual update). Or maybe better still the context menu could have: 'add shade by angle modifier' and 'generate sharp edges from angle'. The sharps should only be created when modelling is complete and the user chooses to apply the modifier (although having a single shading normals attribute that gets modified instead of creating sharp edges would still be my preference).

👍 2

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

blender-v4.0-release

universal-scene-description

tmp_libupdate_41

blender-projects-basics

brush-assets-project

temp-sculpt-dyntopo

blender-v3.6-release

blender-v3.3-release

anim/animation-id-113594

bridge-curves

sculpt-blender

asset-browser-frontend-split

asset-shelf

tmp-usd-python-mtl

tmp-usd-3.6

blender-v3.5-release

blender-v2.93-release

realtime-clock

sculpt-dev

gpencil-next

bevelv2

xr-dev

v4.0.1

v4.0.0

v3.6.5

v3.3.12

v3.6.4

v3.6.3

v3.3.11

v3.6.2

v3.3.10

v3.6.1

v3.3.9

v3.6.0

v3.3.8

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

Labels

Clear labels   

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

This issue affects/is about backward or forward 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

  

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

Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  

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

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

Milestone

Clear milestone

No items

No Milestone

4.1

Projects

Clear projects

No project

Nodes & Physics

Assignees

Clear assignees

No Assignees

19 Participants

Notifications

Subscribe

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#93551

No description provided.