Mesh Auto Smooth and Normals Design Changes #93551
Open
opened 2021-12-01 19:29:14 +01:00 by Hans Goudey
·
14 comments
No Branch/Tag Specified
temp-sculpt-dyntopo
main
asset-shelf
blender-v3.6-release
temp-sculpt-dyntopo-hive-alloc
brush-assets-project
blender-v3.3-release
tmp-usd-python-mtl
asset-browser-frontend-split
node-group-operators
blender-v2.93-release
universal-scene-description
temp-sculpt-attr-api
blender-v3.5-release
realtime-clock
sculpt-dev
gpencil-next
bevelv2
microfacet_hair
blender-projects-basics
xr-dev
principled-v2
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
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports
Apply 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
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
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
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
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
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
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
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
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
Set milestone
Clear milestone
No items
No Milestone
Projects
Set Project
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
10 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#93551
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Background
Recently we have been discussing the best way to expose auto smoothing meshes in geometry nodes.
One of the goals of geometry nodes is to allow more flexibility over geometry data, but also to be easily accessible.
However, currently corner normals on meshes are overly complex and not flexible for a few reasons:
Auto Smooth
is an action applied to meshes, but it in the interface it looks like a property.ME_SMOOTH
) and edges (ME_SHARP
).#68893 is also related.
Changes
Auto Smooth
option, replacing it with a geometry node group that sets the meshsharp_edge
attribute procedurally based on an angle.Normal
input geometry node.short2
), or in a regular 3D float vector attribute.Existing files would not change, and we can still have the simple "Shade Smooth/Flat/Auto" operators.
Implementation
Auto Smooth
option and angle on mesh data blocks:sharp_edge
attribute on edges according to the auto-smooth angle.Mesh Smoothing and Normals Design Changesto Mesh Auto Smooth and Normals Design ChangesRemove
shade_smooth
and replace it withedge_sharp
? Does it mean all meshes will be smoothed by default and only be unsmoothed by assigning sharps?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 :)
On the user level, no.
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
Yes, something like that. We could also invert the
edge_sharp
flag and store it asedge_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.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?
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?
Thanks for the feedback!
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.
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.
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:
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.
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'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.
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.
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.
This solution may solve this task: #107376
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.
Hans Goudey referenced this issue2023-05-02 14:45:37 +02:00