Page MenuHome

Smooth shading usabilty
Confirmed, NormalPublicTO DO

Description

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.

  • Meshes with autosmooth and/or custom normals. This could be either a low poly model for games, or a high poly model imported from CAD software.
  • Subdivision surfaces with creases to define sharp areas of the model. Custom normals are lost in the subdivision process, and autosmooth can't be combined with GPU acceleration.

Once subdivision surface settings become part of the mesh (T68891: Subdivision surface settings part of the Mesh), we could handle these as more distinct cases in the user interface and implementation.

  • If a mesh is a subdivision surface, no autosmooth or custom normals would be available.
  • Subdivision surface mesh primitives could be in a separate submenu of the Add menu, with all faces smooth shaded by default.
  • Mesh primitives could have smooth shaded faces and autosmooth enabled by default when it makes sense.

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.

Event Timeline

Dalai Felinto (dfelinto) lowered the priority of this task from 90 to Normal.Aug 20 2019, 8:20 PM
Dalai Felinto (dfelinto) created this task.
  • Subdivision surface mesh primitives could be in a separate submenu of the Add menu, with all faces smooth shaded by default.

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:

  • Created flatshaded meshes allow to check up it's density.
  • Set Autosmooth operator (space menu - AU) allow to set proper autosmooth that fits most cases.
  • If it isn't somewhere enough we providing sharp edges.

Using it starting from architecture and ending with baroque modeling and lowpoly assets.

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.

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.

one slider for the smooth shading angle. 0° is exactly the same as flat shaded in every scenario.

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.

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.

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?

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?

I have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time.

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 have observed one thing with the autosmooth in comparison to another software, Blender seems to calculate it (realtime) all the time.

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

CobraA (CobraA) added a comment.EditedFeb 20 2020, 10:44 AM

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.

I think the idea by @CobraA (CobraA) in T68893#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.

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)

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?

I think the idea by @CobraA (CobraA) in T68893#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.

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.

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.

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.