Smooth by Angle Usability Improvements #120230

Closed
opened 2024-04-03 20:12:32 +02:00 by Hans Goudey · 24 comments
Member

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.

  • Add "Pin to Last" option for modifiers
    • Replace drag icon in header
    • New modifiers are added above last pinned modifier
    • Disallow drag & drop for pinned modifiers
    • Allow multiple pinned modifiers
  • Change object mode "Shade Smooth by Angle" operator (#121494)
    • Rename to "Shade Auto Smooth"
    • Add and remove modifier instead of destructive action
    • When adding modifier, enable "Pin to Last"
    • Mimic the old redo panel UI
  • Make "Shade Smooth" and "Shade Flat" remove the "Smooth by Angle" modifier (#121494)

Lower priority:

  • Add way to add modifiers to all selected objects
    • In property editor by holding Alt
    • In 3D viewport, a new "Modifiers" submenu next to "Constraints"
    • In outliner, via context menu on object items
  • Improve object instancing ease of use
    • Add "Object" option next to "Collection" for empty object instancing
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. - [x] Add "Pin to Last" option for modifiers - [x] Replace drag icon in header - [x] New modifiers are added above last pinned modifier - [x] Disallow drag & drop for pinned modifiers - [x] Allow multiple pinned modifiers - [x] Change object mode "Shade Smooth by Angle" operator (#121494) - [x] Rename to "Shade Auto Smooth" - [x] Add and remove modifier instead of destructive action - [x] When adding modifier, enable "Pin to Last" - [x] Mimic the old redo panel UI - [x] Make "Shade Smooth" and "Shade Flat" remove the "Smooth by Angle" modifier (#121494) -------------------- Lower priority: - [ ] Add way to add modifiers to all selected objects - [x] In property editor by holding `Alt` - [x] In 3D viewport, a new "Modifiers" submenu next to "Constraints" - [ ] In outliner, via context menu on object items - [ ] Improve object instancing ease of use - [ ] Add "Object" option next to "Collection" for empty object instancing
Hans Goudey added the
Type
To Do
label 2024-04-03 20:12:32 +02:00
Hans Goudey added this to the Modeling project 2024-04-03 20:13:45 +02:00
Hans Goudey added this to the 4.2 LTS milestone 2024-04-03 20:13:49 +02:00
Member

I 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?

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

There's one question mentioned from the https://projects.blender.org/blender/blender/issues/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.
Author
Member

I 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

Thanks, I clarified that. I think all of the above should be disabled, including drag & drop.

Also, can you pin more than one to last? (I'm guessing not).

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.

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?

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.


There's one question mentioned from the #116922 that how to remove multiple smooth by angle.

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.

>I 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 Thanks, I clarified that. I think all of the above should be disabled, including drag & drop. >Also, can you pin more than one to last? (I'm guessing not). 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. >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? 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. --- > There's one question mentioned from the #116922 that how to remove multiple smooth by angle. 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.
Member

Thanks, I clarified that. I think all of the above should be disabled, including drag & drop.

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.

> Thanks, I clarified that. I think all of the above should be disabled, including drag & drop. 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.
Member

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.

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

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.

I am not familiar with the relevant code/mechanism, but some possible questions about the designs are

  1. what if different objects have different sets of modifier, can autosmooth still be recognized correctly for removal?
  2. what if users changed name of the autosmooth modifier for whatever reason. (In fact, should they be able to change the name?)
    etc.
    I guess these can be topics for the module meeting.
> 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. I am not familiar with the relevant code/mechanism, but some possible questions about the designs are 1. what if different objects have different sets of modifier, can autosmooth still be recognized correctly for removal? 2. what if users changed name of the autosmooth modifier for whatever reason. (In fact, should they be able to change the name?) etc. I guess these can be topics for the module meeting.

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?

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

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

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.

> 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?). 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.
Contributor

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.

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. https://projects.blender.org/blender/blender/issues/54862 https://projects.blender.org/blender/blender/pulls/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.

Add "Modifier" option to "Shade Smooth by Angle" operator

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.

> Add "Modifier" option to "Shade Smooth by Angle" operator 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).

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

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

> > 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? > > 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 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
Contributor

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

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

  1. 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, I think other issues will still be present, like linked objects still requiring extra steps to add the modifier to them all.

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

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

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. 1. 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, I think other issues will still be present, like linked objects still requiring extra steps to add the modifier to them all. 2. 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. 3. 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 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.

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.

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.

The Alt workflow when adding modifiers through the property editor is unintuitive, I was about to file a bug report thinking that it doesn't work, not realizing you have to hold down Alt when adding the modifier, not when pressing the Add Modifier button.

The `Alt` workflow when adding modifiers through the property editor is unintuitive, I was about to file a bug report thinking that it doesn't work, not realizing you have to hold down `Alt` when _adding the modifier_, not when _pressing the `Add Modifier` button_.
Author
Member

Yeah, it is a bit awkward. Currently we have nowhere to store the "alt" information in between opening the menu and actually calling the operators.

Yeah, it is a bit awkward. Currently we have nowhere to store the "alt" information in between opening the menu and actually calling the operators.

It's because of multi-editing still not being implemented everywhere.
To my surpise, it works also with enum buttons (for example changing the mode in the bevel modifier from edges to vertices), but not with drop-down menus and buttons (like creating a new texture in the displace modifier).

It's because of multi-editing still not being implemented everywhere. To my surpise, it works also with enum buttons (for example changing the mode in the bevel modifier from edges to vertices), but not with drop-down menus and buttons (like creating a new texture in the displace modifier).

Aside from the fact that I really miss the mesh-level autosmooth option, I think the current implementation has a major issue.
We noticed, while trying to figure out how this new autosmoothing works, that every thing you do with that node tree will also be applied to each new autosmooth modifer.

So for instance, if you for example remove all nodes from the Smooth by Angle node-tree, delete new modifier and then hit W - > Shade Auto Smooth, it will add a broken modifier.

I think this is a huge problem. There should always be an option to add a standardized and working node tree. Right now I can easily destroy an essential tool in Blender for my current file. Even when I save the file and open a new Blender instance and try to add a new Smooth by Angle modifier, it will still add the broken one.

Aside from the fact that I really miss the mesh-level autosmooth option, I think the current implementation has a major issue. We noticed, while trying to figure out how this new autosmoothing works, that every thing you do with that node tree will also be applied to each new autosmooth modifer. So for instance, if you for example remove all nodes from the Smooth by Angle node-tree, delete new modifier and then hit W - > Shade Auto Smooth, it will add a broken modifier. I think this is a huge problem. There should always be an option to add a standardized and working node tree. Right now I can easily destroy an essential tool in Blender for my current file. Even when I save the file and open a new Blender instance and try to add a new Smooth by Angle modifier, it will still add the broken one.
Blender Bot added the
Status
Archived
label 2024-06-11 15:33:46 +02:00
Blender Bot added
Status
Confirmed
and removed
Status
Archived
labels 2024-06-11 15:34:01 +02:00
Iliya Katushenock removed the
Status
Confirmed
label 2024-06-11 15:34:31 +02:00

Realization I had last week: I used to use the Clear Sharp operator... once a month? Now it's all the freaking time, minute to minute.

Realization I had last week: I used to use the Clear Sharp operator... once a month? Now it's all the freaking time, minute to minute.
Author
Member

We noticed, while trying to figure out how this new autosmoothing works, that every thing you do with that node tree will also be applied to each new autosmooth modifer.

Right, that's the issue recently reported in #123082. That's something we're planning on fixing soon. Turns out it's actually quite a deep topic unfortunately.

> We noticed, while trying to figure out how this new autosmoothing works, that every thing you do with that node tree will also be applied to each new autosmooth modifer. Right, that's the issue recently reported in #123082. That's something we're planning on fixing soon. Turns out it's actually quite a deep topic unfortunately.
Author
Member

This is largely resolved, so I'll close the task. It would be nice to add easier object instancing in the future, but it's not very useful to track that here since it's fairly separate.

This is largely resolved, so I'll close the task. It would be nice to add easier object instancing in the future, but it's not very useful to track that here since it's fairly separate.
Blender Bot added the
Status
Archived
label 2024-07-03 16:47:21 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
Asset Browser Project
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
13 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#120230
No description provided.