Smooth shading usabilty #68893
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
11 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#68893
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When adding a mesh primitive in Blender, it is by default flat-shaded without subdivision surfaces. This means that after adding a new object with a smooth surface (like a sphere or monkey mesh), the user almost always has to change some settings.
We could change the default mesh settings to avoid that. However there are two distinct use cases which require different settings.
Once subdivision surface settings become part of the mesh (#68891 (Subdivision surface settings part of the Mesh)), we could handle these as more distinct cases in the user interface and implementation.
Enabling autosmooth by default will negatively impact performance, particularly in edit mode. It's not obvious this is something we want to do. Further optimizations in this area are possible, but there will always be a cost.
Added subscriber: @dfelinto
Added subscriber: @1D_Inc
Can be a checkbox in creation parameters menu?
Creating flatshaded allow to check up geometry polygonage (a "weight"). Indeed, it is very important for gamedev.
We solved autosmooth issue in a simple way - created Set Autosmooth operator that applies 70 degree autosmooth to selected models.
70 degrees allows to keep pentagonal cylinder as flat and hexagonal cylinder as smooth, so it very profound value for most cases we faced with.
So we has got very simple unified workflow:
Using it starting from architecture and ending with baroque modeling and lowpoly assets.
Added subscriber: @JonathanLampel-4
I think we could improve usability here quite a bit without any performance cost.
Let's say we hide the Auto Smooth toggle completely and only have one slider for the smooth shading angle. 0° is exactly the same as flat shaded in every scenario, so internally Auto Smooth would be off. This could be the default with no performance hit. 180° would be the same as smooth shaded, unless edges are marked as sharp. So if no edges are marked sharp, Auto Smooth is also off at 180°. If the angle is anywhere in between or if any sharp edges have been set, Auto Smooth could automatically come on behind the scenes. Setting smooth and flat shading would then not be setting a property of the object but setting a preset for the smooth shading angle.
The benefit of this is never having to think about whether something is set as smooth or flat shaded, or if auto smooth is off or on (warning signs in modifiers, setting sharp apparently doing nothing without any explanation, etc.) - it would all just work as expected and be a faster workflow.
Sounds similar to sketchup solution, also, as far as I remember, same behaviour were used in some shader nodes.
So why not, I can’t find cases in which this solution causes problems)
I will ask webgl modellers, such things are always fragile in gamedev/realtime.
Asked webgl artists.
Indeed, smart autosmooth slider seems to be ok, if "shade flat" and "shade smooth" options will be available for mesh editing.
This way, placing smart autosmooth slider to adding object preferences with default=0 seems to be a nice solution both for usability and perfomance issues.
Added subscriber: @WilliamReynish
Some apps make it so Smooth Shading is always enabled when using Subdivision Surfaces. If we did that, or had a boolean to enable this in the modifier which was enabled by default, that would make the process of achieving smooth shapes simpler.
Indeed, a boolean can be a nice option.
For instance, in gamedev modeling subd flat shading will allow to percept mesh density, while in organic/hardsurface modeling subd smooth shading will allow to see smooth result immediately to check up for artifacts with zebra shading.
https://youtu.be/mIpJq9y_Qic?t=237
An excellent example of automotive modeling.
Car is made in flat/autosmooth shading, because it allows to feel an actual geometry, and subd with smooth shading option allow to see the final result of every part.
https://youtu.be/757ZnC7bPF4?t=639
Global checkbox that allows smooth shading for subd will be useful, as it's state depends on gamedev or hardsurface workflow type that artist performs.
Added subscriber: @Bango
Wouldn't it be user-friendlier to implement a setting in the preferences where the user can preset the angle value of auto smooth for future projects/assets himself?
Added subscriber: @CobraA
I have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time.
Here is Blender's example, while the other DCC the users have to "apply" autosmooth when they need it, it doesn't happen each time you change angle of the edges ...so is this what impacts the performance?
{F8350411 size = full}
This feature is used in organic surface modeling to set geometry angles to a specified autosmooth. It allow to see if surface have wrong tension and curvature and quickly set correct one.
That's one of the reasons Blender is so good for optimized organic modeling.
I don't get your point, my question is about performance not where this feature is useful for, I assume everybody knows that already.
I think we both are not sure what this question is about)
Is it about removing a feature to increase perfomance to satisfy some users? This is how this question sounds like.
For sure, any kind of realtime calculations lowers perfomance, but in this case It depends on the workflow, we cannot accept removing this.
Also what is "DCC" by the way?
p.s. aw, Digital Content Creation from UE/gamedev.
Well, it seems you indeed just asked, sorry then.
We have had a lot of things spoiled recently due to such things, so we have to be careful.
Am i talking to a bot or something? because your replies don't read as human at all.
I think it's best to let a Dev answer this kind of questions, My point if this constant live update of smoothing is causing a huge performance slowdowns then maybe a different approch should be taken like the other DDC(Softwares)
I would take huge performance boost over fancy live update any day.
Added subscriber: @brecht
I think the idea by @CobraA in #68893#876084 is a good one. Autosmooth in general is not something you even want to change as you deform the mesh with modifiers, because then it pops in animation. If you do want it then an explicit edge split modifier should probably be used instead. So replacing autosmooth by a way to update sharp edge tags while in edit mode make sense to me (either manually or perhaps automatic for tools like transform if desired).
This helps with performance, but only in part. Autosmooth involves both detecting which edges are supposed to be smooth, and then computing normals based on that information. So to make it really low overhead, we may also need to reconsider how to store and update the normals.
As it was already told by developers, there is nothing much to do with that perfomance issue whatever it is.
There always will be a cost.
Devs are not familiar with other software, so you can accidently trigger activity after a question, like removing realtime update, bringing down several workflows.
Can you, please, post some gifs from other software as well to clarify the solution you want to propose and avoid interpretations?
The problem is that autosmooth update is very workflow dependent feature.
As displayed on example above, it's realtime update is needed for organic modeling process.
Also, in some cases it is acceptable to freeze sharp edges with manual sharpness assigning + split edges modifier, some cases - not.
For instance, in architectural visualization a house with autosmooth may have 1mln vertices, but with edges splitted - about 2 mln, so it can make troubles for scenes with lots of such houses and also exports to other software, so we are using autosmooth for that cases.
For sure, it will be nice to have ability to bake/apply autosmooth normals calculation result without splitting edges (make it static with the ability to revive and edit it with autosmooth sessions, maybe in yavne addon style) or, for instance, the ability to convert autosmooth sharpness result to a sharp edges, and make special smooth mode that will support only assigned sharp edges, but, in general, it feels like a separate, huge and case-dependent task to design.
Added subscriber: @AnityEx
suggestion:
add a check box called like "live autosmooth" on/off
on= realtime autosmooth (like always)
off= leave it with last autosmooth operation until you press a button again
then make live autosmooth on by default to not break any old file for users
Such a suggestion is far away from being complete - it is not even explained is it about scene or per object.
Added subscriber: @MadMinstrel
I think the live sharp update and normal calculation is an excellent feature for low poly modelling (that is to say virtually all modelling before the model gets complicated), and I wouldn't like to see it go - until you hit the several-thousand-vertices threshold when performance starts to chug anyway.
The edge-split modifier as Brecht proposed would work of course, but it's a non-obvious solution to a problem that doesn't currently exist. Especially to newbies. I'd suggest to keep it working as it is by default, but allow it to be turned off.
Added subscriber: @Znio.G
I was testing some mechanical rig and it seems that autosmooth impacts the performance greatly, if you disable it you get almost double the FPS back but without it you won't get proper sharp edges.
I think this is a breaking point for Blender as it's not only impactful in modeling but also in animation.
Basically you have to choose between performance or the visuals.
I personally wouldn't use it because of that but maybe it could be baked or a new manual option that doesn't halt peformance to this level.
Added subscriber: @HooglyBoogly
I wanted to mention #93551 here, since it's very related. I think the changes here and in that task are somewhat compatible, but I do think the idea of moving auto smooth to an operation instead of a setting would be helpful here too.
Hans Goudey referenced this issue2023-03-04 19:04:19 +01:00