I just realized that autosmooth was there next to shade smooth and shade flat and I never even noticed
1 Like
sure it is -
Tried the new autosmooth thing and I can live with it. I can see this becoming more frequent with node groups and tool assets so I might as well get used to it.
Same. I always used the one in the mesh tab, making it way harder on myself.
9 Likes
I have been playing around a lot with this over the past day. Since I had been following the development of this, there was no doubt in my mind that this was bound to cause a LOT of confusion in the community when it was released. This feature was originally going to be added to 4.0 but got changed to 4.1 late in the bcon cycle.
Personally, I love the way that most mesh properties have turned into attributes, and it must have been a lot of difficult work for Hans to get it this far, so kudos to him for taking this initiative!
There are a few weird eccentricities though, so it will take a little getting used to. I actually would have preferred that the sharp_edge and sharp_face attributes were permanent attributes (like position) that were on every edge/face.
Currently when you add a primitive it will have the face sharp attribute with all faces attribute set to true. If you select all but one face and do a shade smooth operation, all of these face attributes will be set to false. However, if you select the final sharp face and make it smooth, the sharp face attribute disappears altogether. .
Not sure why the attribute is not kept will all faces set to falseā¦maybe this helps performance? As soon as you tag one face to be smooth, the attribute is then recreated.
Additionally, there is the sharp edge attribute that can also define smoothness based on edges. While this is great to be able to define smoothness based on edges and/or faces, having the attributes appear and disappear in the list is a bit disconcerting. Anyway, now that I understand how it works, I can get used to it.
I didnāt really tend to use the auto normal smoothing anyway, so that is not a big deal for my workflow. You get a much better result using the weighted normal modifier and defining sharp edges. You can then also tag faces as being weak or strong to get further control of normals. This is particularly important in a game pipeline. The good thing in 4.1 is that the face weighted normal workflow is simpler, since a mesh is assumed to be fully smooth unless you start adding in sharp faces or edges (as attributes).
This image shows a simple mesh shape with auto smoothing modifier on the left and the face weighting modifier on the right.
I do hope to see the face weighted normal attribute get better attribute naming though, as is currently takes up a lot of room and uses āmagic numbersā for the face attributes. Not sure how 16384 denotes strong influence and -16384 is weak. You would think that 1, 0, -1 would be the best to use and looks better in the spreadsheet.
8 Likes
Thanks for the feedback!
Right, it is about performance. Currently we have no way to store an attribute as a single value internally, so we make use of the āfalseā default to avoid storing the array to save memory and processing. Eventually the attributes can be more permanent when there isnāt a performance tradeoff.
I hope we can make the weighted normal modifier into something more generic (at least internally) when we have the ability to control custom normals in geometry nodes. Iām honestly not even sure why it needs to store an attribute.
14 Likes
The benefits of auto smoothing being generic attribute based are enormous, but I do think there will be lots of issues related to instancing and the fact that when auto smoothing remains a modifier, itās tied to the object, not the mesh.
I think that the implementation of modifier based auto smoothing uncovers deeper flaw of blenderās core design in that the modifier stacks canāt be instanced.
I think that in near future, it will be necessary for Blender to re-think the concept of instances (not internal GN mesh instancing, but scene-level object instancing). Since modifiers operate on mesh, the mesh instance can no longer be thought of as just one mesh data-block in memory used\referenced by multiple unique object containers, but we also need a concept of instancing the evaluated result of the entire modifier stack. Not just the base mesh modifiers operate on.
This would solve both performance/memory concerns as well as scene management concerns (changing modifier properties across many instanced objects).
EDIT:
I think there are 5 base states that should be possible:
-
Objects with no modifiers and unique mesh data-blocks:
There are multiple unique meshes in memory. -
Objects with no modifiers and shared (instanced) mesh data-block:
There is single mesh in the memory instanced at multiple places in the scene. -
Objects with modifiers and unique mesh data-blocks:
There are multiple unique meshes in memory and each modifier stack is evaluated on each object. -
Objects with modifiers and shared (instanced) mesh data-block:
There is single mesh in the memory instanced at multiple places in the scene but each object then evaluates its own modified mesh, costing performance to do per-object modifier stack evaluating and negating any benefits of instancing (the modified mesh becomes unique copy in the memory). -
Objects with instanced modifier stack and shared (instanced) mesh data-block:
There is single mesh in the memory which has a modifier stack evaluated only once, and then the result of this modifier stack is instanced at multiple places in the scene. This saves time/performance since modifier stack is evaluated only once, not once per object, and memory, since thereās only one copy in the memory, not one copy per each scene object.
Blender can currently do 1-4 but canāt do 5.
There would need to be a few things figured out:
- Some UI to indicate the modifier stack is instanced.
- Instancing the entire modified stacks is not the same thing as being able to instance individual modifiers. The latter would open up some flexibility but defeat most gains in terms of performance and memory savings.
4 Likes
One thing that no one yet mentioned in this thread is that finally hidden option of autosmooth on 180Ā° is finally gone and sharp edges work without that.
Also it can be disabled in edit mode to save performance on heavy meshes.
Yea, There is lack of āobject instanceā type.
You can instance whole collection, You can instance within GN, but You cant instance object. There is only option to reuse mesh data (alt+D), but that have it owns drawback of lacking shared modifiers.
3 Likes
Node Panic at full swing again I see.
I havenāt downloaded alpha, so from your videos, we can use right-click operators to shade smooth, flat or auto smooth JUST AS BEFORE, no change whatsover, AND I also have GN modifier which can use attributes?
I donāt get it, whatās the downside? That seems like fantastic upgrade. Iām lost. Weāve adressed that UX-wise there is no change, except IF you decide to use modifier you need to copy it on selected objects. One more click, no biggie.
But I think Blender should have way to add modifiers as operator, similar to Add Constraint operator in Object menu, that would mean 1 less click again.
Is Shade Smooth by Angle using node tool under the hood to set attribute?
About 3dsmax: Its not correct to compare, as 3dsmax has to types of instance. Reference copy the object incl. all modifier to the state they got copied and instances copy the object incl. all modifiers in an active link. So 3dsmax user benefit from real good performance even when using modifiers on instance, because they are true instances, with the exception of references. So any object with Subdivision will be seen as instance, not as a copy. Plus Subdivision and smoothing is in the base mesh, no need for modifiers.
About Modo/C4D: They both use passive and active instances. A passive instance canāt be edit, its basically an empty pointing to another object inheriting everything in modifier stack. An active instance, is deformable and can have additional modifiers, similar to reference in 3dsmax.
Blender got none of the above, hence its performance suffer. For example you add deformers on a tree to generate wind animation. Each copy of the tree is its own mesh, even if you linked the mesh. Only work around is via collection or geometry, the only way to get instances in Blender.
Now they made it even worse.
5 Likes
Thanks for the reply Hans! I figured it was for performance reasons. I am looking forward to the mid 4.x era when most of these teething issues are ironed out, including custom normals. Great job so far with the āeverything is an attributeā work so far, as I know it is far from trivial.
One other bit of feedback is related to the bundling of node groups like āsmooth by normalā. Maybe it would be best to not be able to modify the default builtin ones. I quickly realised that if I modify it, then if I try to add it another one via the modifier list to another object I will get my modified version and no way to get the original bundled one back in that scene ( as far as I can tell).
If in the future there are lots of bundled node groups for basic modifier tasks, maybe it would be better to have to make a duplicate of the bundled node group for those that want to tinker āunder the hoodā?
1 Like
I think thatās issue in modifiers panel, but in geometry nodes when you search for it, if you add it from Group menu, it will add your modified version, and if you add from correct category, it will add original one. I tested something like this couple of weeks ago and I THINK this is what happened 
The difference is that the modifier is required for procedurally updating edge sharpness as the mesh is transformed or edited. The idea is to make that behavior explicit and controllable with Blenderās existing tools for such operations. Maybe it will be helpful to have some more features for dealing with modifiers on many objects.
Thanks! 
Yeah itās been a big project, pretty satisfying work though.
Yes! Weāve been talking about ālockingā the appended assets. Iām hopeful we can get to that for 4.1. I made a design task for it here.
8 Likes
What do you mean?
Two instances of Suzanne, one with subdiv modifier, other with no modifiers. Active instance as you call it. And you can create āpassiveā by adding Suzanne to collection and instancing collection instead.
Not to mention ability to instance in nodes
1 Like
If you are using the right click menu to do this, no nodes are added. If you look at the attribute list, you will see that sharp edge attribute is added with edges within the selected angle are tagged as true with the sharp edge attribute.
A good way to think of it is that by default all mesh faces are shaded smooth and that you override any edges or faces by tagging them with the sharp egde/face attribute. This is why the attribute disappears when there is nothing tagged as sharp.
The smooth by angle is just doing this procedurally, so that if you then apply the modifier, the sharp edge attribute will then be added to the attribute list for that object.
I see. Some tools are needed indeed. Add Modifier operator as I said it could be quick fix.
Have you thought about adding modifier automatically when you shade by angle in right-click menu? Iām thinking maybe that can be better workflow, as it seems youāll always need modifier and itās just unnecessary step at this point we have to make ourselves.
About locking assets. Is there a way to unlock? Iām modifying hair assets for example here and there, Iād like to keep that ability. I think āRestore Assetā operator would be best, in node sidebar it can be single button that undoes all the changes and if the name matches to the one in asset browser, just replaces modified one with asset one.
1 Like
Yes but Iām curious how that attribute is added and deleted. Node tools can do that now, I wonder if itās done with node tool operator, or is it internal code.
Look at the statistic. And please try to read a bit about 3d technology. Instance is a copy of the original. Identical and taken from the state in viewport. Blender reference the mesh data and a modifier breaks the instanceā¦ any modifier does that, because its not anymore the same state of mesh. How many times I have to explain that?
And youāre saying in Cinema 4D, you can instance a monkey, subdivide it, and it will not add new faces in the statistic? Can you provide visual examples of what youāre talking about?
BTW, theoretically we could extend Blenderās automatic instancing support to handle cases where the object data is the same and all the modifiers are the same with the same input values. That would be a bit of work, but probably isnāt too difficult on a design level.
17 Likes
Most of time when you instance, you donāt change instanced mesh on the fly.
So, Sharp Edges not being set automatically can do the job.
And if instanced mesh is changed dynamically, a Geometry Node modifier can be instanced, too.
When modifiers are Geometry Nodes modifiers and values are tweaked in nodetree, Blender handles case 5.
And the plan was to convert all old modifiers into Geometry Nodes nodtrees.
Creating a library override is supposed to have a better performance than making the mesh local.