Smooth by Angle Usability Improvements #120230
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
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#120230
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?
A followup to #93551. A combination of overall modifier usability tasks meant to improve the overall node group asset modifier workflow, and specific improvements to the "Smooth by Angle" modifier to ease some specific workflow shortcomings.
AltI guess by "Disable reordering pinned modifier(s)" you imply changes in what happens with the "move up", "move down" and "move to index" python API operations (and UI operations for the first two), but perhaps you should document here exactly what you mean. Also, can you pin more than one to last? (I'm guessing not).
Some of the user upsettedness seems to be about the mere presence of modifiers at all as a necessity. I think this may be a matter of perceived "clutter" in their Blender interface, more than any functional issue. Have you considered a "pin to last and hide" operation instead, with a "reveal hidden" button if you want to see it?
There's one question mentioned from the #116922 that how to remove multiple smooth by angle.
I am not sure if it will be a problem in the practice, but I think it's worth to mention it here.
Thanks, I clarified that. I think all of the above should be disabled, including drag & drop.
Some users have mentioned this would be helpful, so I'm leaning towards allowing it. I would still disable reordering of pinned modifiers completely I think, it would be too tricky to only allow reordering within the pinned group of modifiers.
I think keeping these operations visible is one of the benefits of the change, and that we should lean into it rather than trying to hide these details. In the future we hope to switch to a more standard list UI for the modifiers anyway (#111538), where a single modifier would take up less space.
Maybe eventually we will need the ability to hide modifiers, but because of the complexity that brings, I'd view it as a last resort.
Good point. I don't have an immediately obvious idea for that, but it would be nice to handle. Maybe holding "alt" when pressing the X button could work as well? There's also the option of making "Shade Smooth" and "Shade Flat" operators remove the modifier, but I'm skeptical about that.
Also need to clarify that for the non-pinned modifiers, you can't move them down past the pinned one(s), either with 'move down' or 'move to index' or drag&drop.
I know you just want to get this done and done quickly so feel free to ignore. But another idea that might make users happier would be: have a "global bottom modifier" stack that is applied below every object (or every Mesh object?). This would have the advantages that (a) they wouldn't clutter the stack of every object; and (b) newly added (Mesh?) objects would automatically get that stack applied too; and (c) instant global on/off of the shading modifier everywhere. Of course the disadvantages are (1) more time to develop and debug, and design needed for UI and menu and Python access to this; and (2) less transparency to user about what is really going on.
I am not familiar with the relevant code/mechanism, but some possible questions about the designs are
etc.
I guess these can be topics for the module meeting.
For some, it's not an issue of visual clutter whatsoever. It's that relevant objects must now be assigned modifiers, which have to be monitored, adjusted, managed etc when modeling and exporting.
In other words: the problem isn't merely seeing a room filled with children. It's the requirement to babysit these children.
I like this idea but what about a bit more expanded: Add the concept of a Scene modifiers panel that applies modifiers to all objects in the scene. In the object level modifiers, there is a representation of the Scene modifiers that allows the user arrange the object modifiers before or after the Scene modifiers as necessary. This would all be in addition to the pinning and other functionality Hans has described in the original description.
The problem with the Alt key for multi object editing is that it's really frustrating to use. I use Blender for years now, and I still don't remember whether I have to hold Alt key while invoking the UI element, or while confirming it.
So in example of Add Modifier menu, do I holt Alt before clicking the Add Modifier button? Or do I hold alt when I have already the Add Modifier menu open and I am about to confirm the selected option? Or do I hold Alt during both of these operations? It also seems this Alt "moment" is quite inconsistent between different UI elements.
I think we should solve this by finally, after years, finishing the multi-object editing, so that changes of object properties are done to all of the selected objects where it applies, and Alt key would opt out of this behavior, not opt-in.
#54862
#111093
Once this is done, given how confusing the Alt workflow is, most users will resort to just selecting single object if they want to edit just it, instead of visually tracking which which of the selected ones is active, and then fishing in their memory which is the right alt-to-click-to-keypress order in order to trigger it.
When multiple objects are selected, we could also have some UI visual indicator if which properties are editable on all selected objects VS on active object only. (Those for which the Alt key currently does nothing)
But addressing this beforehand, before we possibly move more object/mesh attributes to GN modifiers, will save us a lot more headaches down the road. Imagine how less stressful and reliable would it be, if simply using the Add Modifier menu like normal would result to adding selected modifier to all the selected objects, instead of just the active one.
Yes, I would actually bring this even further by removing the setting sharp angle option in object mode and keeping it only in edit mode. In object mode, we should have the previous text "Shade auto smooth", which will automatically add the modifier.
One of the things that threw people off the most in the 4.1 change was changing the shade auto smooth entry in the right-click menu to the entry that creates sharp edges. By watching videos online, I can tell you a looot of people doesn't even know about the modifier, and they think auto smooth was replaced only by setting sharp edges.
This might be a larger project, but I feel like a big issue with the Smooth by Angle modifier is that it works on object-level, not data-level (Alt+D an object with the modifier and notice how the memory and polycount in the scene goes up, unlike if you were to do it without the modifier).
I feel like a solution to this would be a separate data-level modifier stack (shared between objects, works with Alt+D, an object can have both object and data modifier stacks but the latter is applied first).
i agree with this. i think the new features are quite usefull, i wouldn't remove the new Smooth by Angle nor the Smooth Shader modifier, but i think the previous Auto-Smooth feature wasn't broken from the perspective of user experience, lots of people use it, especially hard-surface modelers
was it broken under the hood? yeah, maybe it was inefficient, but if we can achieve the same functionality as before (being able to apply the Auto Smooth and forget about it, not having to take care of it in the modifiers panel, etc.), it would be ideal then, so we can have the best of both worlds
@HooglyBoogly one of the issues I encountered which I didn't think of when testing, is that I often use "Visual Geometry to Mesh" to apply all modifiers when modeling. And after doing that I have to re-add smooth by angle again. What do you think if pinned modifiers didn't get applied when calling that operator? Or if there was an option for it in redo panel. Not sure if its possible since its conversion of mesh internally, but...
After reading the original proposal for the changes to Autosmooth, this seemed like a necessary and good upgrade in ways. Though as primarily a hard surface modeler that uses Autosmooth often, I share the concerns with the workflow becoming more complicated, even if the changes here are implemented. I honestly wouldn't know how to make everyone happy here, but I had some thoughts.
I believe a Right Click option to add a modifier is a step towards restoring usability, but I agree that modelers don't want to see and monitor a new modifier for what was all automatic and invisible before. And even if pinned at the bottom of the modifiers, and aside from visual clutter, a modifier presents workflow issues still. Like what happens if I have a Smooth by Angle modifier and later want to change the shading to fully Smooth shading? Instead of just Right Click > Shade Smooth which turned off Autosmooth automatically, I would need to go to the modifier properties and delete the modifier. This is an extra step if I don't have those properties open already. Small nuisance, but it adds up. Plus I think other issues will still be present, like linked objects still requiring extra steps to add the modifier to them all.
The only solution I can think of that could possibly address all complaints, is to restore the original mesh-level Autosmooth option while also keeping the new object-level modifier. Currently, the Right Click menu gives us a mesh-level option that works differently than the original(and is much less useful in my opinion), and then we also have a modifier for object-level. So, both mesh-level and object-level options are already offered. My proposal is to restore the mesh-level option to the original Autosmooth to address all concerns there. When Right Clicking, there would be Autosmooth options for both mesh-level (activates the original Autosmooth) and object-level (adds in the new modifier). One problem with this is that the issues with the original Autosmooth might need to be addressed, like maybe making Blender automatically enable Autosmooth when some modifiers require it for example. But other concerns, like deforming meshes always having their autosmoothing recalculated, can be addressed by using the modifier instead.
Also, on a different note, as a teacher I see a lot of confusion in new users when there are name changes, even simpler name changes, as it adds a degree of confusion to every tutorial out there. In this case, the switch from "Autosmooth" to "Smooth by Angle" didn't seem necessary to me at that cost, and "Smooth by Angle" seemed more like what the tooltip for Autosmooth should say. So for the sake of new users and the entire documentation and tutorial database, I'd like to request changing the name back.
Just my thoughts on everything, and thanks for the hard work.
I think a simple solution is to restore the workflow, using the new system under the hood. As mentioned by others, babysitting modifiers stinks, especially when working with hundreds of objects. The old system had numerous flaws, but they were primarily due to the way the smoothing was working under the hood. The new system is great, the new modifier is great. I certainly don't want to revert the codebase to the old method!
However, as a user, I just want to be able to do what I used to do: right click -> Shade Autosmooth, and then ignore it forever. For 99% of objects I don't even need to set the initial value to anything other than the default 30 degrees. Behind the scenes, the new system is being used, but the user isn't required to babysit or even see that there's a modifier on their stack doing this.
This may be a little less elegant, since it would require hiding a modifier that is always moved to the end of the stack behind the scenes, but I think it's worth for the user experience. We already have the idea that modifiers can warn you about things - the Subdivision modifier tells you if you're getting the benefit of the GPU or not. Adding a Smooth by Angle modifier could warn you "Hey, you are using the 'autosmooth' property already and I am being overridden/I am overriding that". Elegance is great, but workflow efficiency is better since at the end of the day software should make the user happy, not the source code :)
It should be noted that this is a very standard workflow - every major DCC has it in some form or other, with the exception of 3dsmax. Every one of my blender-using colleagues were aghast when they saw this change. I'm very glad to see that this is getting attention. I myself haven't upgraded from 4.02 solely because of this one issue.
I didn't really suggest reverting anything, but to continue using in conjunction to get the best of both worlds. I'm not fully aware of the how the original code worked, so it might not be the best solution to keep both in place, but solely using the new modifier doesn't offer a mesh-level solution so extra work will be needed to address some issues mentioned. Simple example, if I link duplicate an object, then I add autosmooth to one object afterward, the linked duplicate won't inherit this. Unless there's a simple solution here I'm overlooking? This proposal has an option to add modifiers to all selected objects, and this will work but the extra steps are not ideal. Using the Right Click option is not a proper solution here since it's destructive and doesn't update automatically. I don't know the best solution for all of this, but judging by the proposals and discussions, it seems like trying to make the modifier work for every consideration may become a pretty convoluted task.
Oh I wasn't saying you were, sorry. I just wanted to make clear that while I'm looking backwards to a better workflow, I'm looking forwards to a better system if that makes sense. Progressive, rather than regressive. And yeah you have a point about the modifiers not propagating to linked objects, which is a big problem.
I'm not sure what the solution ends up being; I just know that from a user standpoint, the old way was perfect - easy, almost always set-it-and-forget-it, automagic, requires no babysitting. The new way is the opposite of those things, from a user standpoint. I just hope we can get the benefits of the new smoothing system without the big workflow regression we have now.