Modifiers UI Overhaul #111538
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
22 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#111538
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?
The Issue
The user interface for managing modifiers has barely changed since its inception in the early 2000's.
A modifier has always been a "panel with settings", where the interface was made as compact as possible to fit many modifiers on screen at once.
Some modifiers had way too many settings to fit in the stack so they were given their own context, such as Particle Systems or Physics. These are still modifiers and show up in the list as such, but they show a "Settings are inside the -context- tab". Not ideal.
In recent years, users have gained the ability to build their own modifiers using Geometry Nodes. This has led to incredibly complex modifiers featuring long lists of settings.
There has to be an easy way to list, and tweak modifiers.
The Solution
Lists.
This is not a new idea. Lists have been proposed several times with the oldest record I could find dating back to this PDF from 2014 by Cole Reed. As well as design tasks, RightClickSelect proposals, community hacks, and add-ons.
This was proposed over the years again, with the most recent being for Blender 3.0. The main reason against turning the modifier stack into a
UIListwidget is the loss of the nice drag & drop that was added back in 2020. With the new List widget this will no longer be an issue.The List
A list will contain all modifiers for the active object.
Adding and removing modifiers will be done via the familiar
+and-icons, same as in every other List in Blender.Visibility settings for each modifier will be icons on the right side. Dropdown items to
Apply,Apply as Shape Key, and so on, will be in the dropdown button (under+/-). This dropdown could contain new operators that apply to the entire stack. LikeApply All Modifiers,Delete All Modifiers(some operations part of the popular Modifier Tools built-in add-on).Modifier settings will still be inside a panel as it is currently, but the panel's header will be much simpler since visibility toggles are in the list now.
The
Particlestab goes away. Particles Systems show up in the list of modifiers. When a Particle System is active, their settings will show up in a panel. All panels currently containing particle settings will be sub-panels.Most of the physics systems will show up in the modifiers list as well. With the exception of those that are not part of the modifier stack (Force Fields and Rigid Body). Each physics system will be a panel (just as it is currently).
Multiple Items
Optional. Just food for thought.
One modifier must be active, but several could be selected and displayed at the same time, to easily compare values or apply settings to multiple at once.
The Add Menu
Implemented in !111717
The current menu has issues:
But the main issue is that it can't be extended. Users could make their own modifiers and have them show up in the Add menu.
Similar to the
Add ObjectorAdd Nodemenus, a new list-styleAdd Modifiermenu will look more familiar and be easier to navigate. With the upcoming search in menus feature allowing to quickly find what we're looking for.(mockup using the current categories as example, this should be re-organized once the new system is in place)
At the bottom of the menu there will be our custom-made modifiers, grouped by catalogs, similar to how Node Group assets show up in the
Add Nodemenu in Geometry Nodes.To make adding modifiers faster, users can press
Shift+Awith the mouse over the properties editor to spawn theAdd Modifiermenu.Conclusion
Again, this is not a new idea, but I believe Blender now has many of the pieces required to make this finally happen (the new Lists view, node/modifier panels, modifier assets).
This will make it easier to replace (and improve) the current modifiers with the help of the community, and make custom-made ones integrate seamlessly.
Plan of Action
This project will need a team. Some of the work can be done simultaneously by two devs, such as the
Addmenus is a separate project from the List display. A designer should be involved, and feedback from the community as always.Object modifiers would be the first to tackle but future work will be needed for bringing this (or similar) interface to:
Related Tasks
Hans Goudey referenced this issue2023-08-30 06:09:23 +02:00
I want to support being able to have multiple modifiers selected. Sometimes you work with multiple modifier values, tweaking to see results, and having to constantly change active modifier in the list will be backwards step. That is one of the most annoying things in Cinema4D as well, constant need to switch context in properties
+1 For the modifier list workflow. Have used the addon and a similar UX for years, this workflow is indeed less cluttered and nice.
The added benefit of highlighting or listing multiple selected for drivers/animation sake, would be an added bonus. (no need to select one, copy, select the other, paste vs. select both, copy then paste)
EDIT: I've also had a number of users request the search field add top-level (or sub-menu) entry too, which the Modifier List addon also implemented - highly recommend.
Hi,
I personally love the ideas!
About the menu
But I also foresee that some people might prefer the current list display. I've heard some people and cultures perform better with a bunch of info displayed at once rather than having everything tucked away. Some people have grown some muscle memory for the current menu and would struggle (at least temporarily) with another display. Is it conceivable to have the two menu displays available, even as an option in the Preferences? Though maybe I'm overthinking it.
Would this menu replace only the one we get from the Add Modifier operator, or also the one from the Add Modifier drop-down in the Properties Editor?
About the UIList
If this new design is adopted, would this occasion be used to globally modernize the UIList?
You do mention that the only downside for modifier would be to lose the drag'n'drop from panels, so will this be addressed with the new List widget? Will it also keep the ability to press CTRL A over a modifier in the list to apply it (or at least apply the selected ones)? And would these changes propagate to other UILists in Blender such as Vertex Groups, Shapekeys, Materials, addon-made UILists, ...?
I love the idea of being able to select elements in the list to display their relative info. Would this be possible to use for bulk managing as well? I.E in other UIListlike Shape Key, you could easily bulk rename, change their values, duplicate, delete, paint multiple groups or color attr at once, and so on... Infinite power!
I reckon this can quickly go outside the scope of this task, but I've been frustrated with this UIList for long x)
UI Lists are indeed quite limited. I would like to replace them longer term with the much more flexible/powerful UI views. As a first step we can make UI lists use tree-views internally, and see if we can expose some of its features to UI lists. This is also what we're considering for this task.
Hopefully we can expose them in BPY in future too.
UI views include some drag & drop support for items, but we have to figure out how UI lists would hook into that. Some code has to handle the updating of the data-set order when dropping items. I'm a bit skeptical that we can have a generic implementation. So scripts using UI lists would likely have to be updated to support this, e.g. to have an operator that handles the reordering on drop.
UI views can support selecting multiple items (implemented in a branch already) as a first step. I think most operations could support batch editing quite easily, but the devil's in the detail of course.
I have to say I'm not a fan of using the UIList or UI Views for the modifier properties. The current layout of one unified list of panels is quite elegant. Expanding/collapsing via dragging can quickly give an overview of the entire stack. Reordering them is simple and fast via drag & drop. There's no duplicated information and no need to select from a list first. If a modifier takes away too much space, it can be collapsed.
Having a long UIList at the top takes away space for the actual modifiers.
Kinda reminds me of #76023, which suffered from similar problems.
Would be great to get some more opinions from modifier power users like @SimonThommes
I have to say that I agree with @JulienKaspar
I personally work a lot more in the node editor than the modifier stack, keeping the modifier level really only for the highest level operations. That means I don't end up with a very long list of modifiers anyways, even in complex cases it stays manageable.
If that is generally the direction that we want to move into (which is what I personally understand), I don't really see a good reason to invest development resources into this direction in my personal opinion.
I do think there is great value in how right now one modifier and all its information is in one spot in the UI. Visually separating the UI into two elements takes away from that quite a bit imo. This idea would make more sense to me if we wanted to introduce things like modifier groups, where every UI list element would be a drawer of multiple, logically connected modifiers. But even then, in the light of moving more and more into a node-based workflow, and using the modifier stack for the high level interaction, I don't really see enough of a benefit personally.
Another aspect, that I just want to mention is that for the procedural texture nodes project will need a way to represent layers that are define in a node-tree in a flat list of layers. It's still unclear how exactly that will works but it's clear that there will be something. To me it would make sense to potentially go in a similar direction with modifiers. So I'm not sure how much it is worth revamping this before we know how that will look like.
The part about the add menu is something I was already familiar with and I think it will be very helpful.
This functionality could be kept with the introduction of a "selection toggle" (checkbox-like?), like collections have in the outliner. This "selection toggle" would allow the user to click and drag to select/unselect all of the modifiers which, in this proposal, displays the settings of all the selected modifiers concurrently.
I would love this to be finally implemented! Try modeling with 10 + modifiers with the current modifier tabs, it's not a good experience! The amount of time just managing the modifier tabs, opening and closing them are insane and I see very little benefits.
After using the modifier list addon I can't go back and I recommend anyone who still is unsure to test it for some days while modeling with a bunch of modifiers. There is a reason this feature has received so many hearts and upvotes and that other industry standard software also does their modifiers in a list. Everything is more compact, clean and easier to overview while doing more complex modifier setups. Even if you just use one geometry node modifier, I don't see any cons compared to the massive benefits for modeling with a lot of modifiers. Also as a bonus we can finally fit longer modifiers without any issue and finally remove the unnecessary and badly designed physics tab.
If there's still users who want to use the old way of doing things, there could be an option in the preferences.
Also it could be useful to do a poll to see what the community would prefer to be the default.
Wondering, could those physics types that aren't currently modifiers (Force Fields and Rigid Body) be moved to Constraints? Or even moved to the Object tab somewhere?
Otherwise, the current Physics tab might seem redundant if it's almost empty anyway?
As example from PR: #111995
Modifier can have multiple operators, callable from down arrow menu. It would be make more seems to have multiple buttons for such operators.
The list sounds great if you're using a lot of modifiers, but awful if you're not. If you don't have many modifiers, the list will just take up space and separate the modifier's options into two different areas instead of all of them being in one place in the stack. The main problem, though, is I really don't want to have to select a modifier each time I edit it.
The optional proposal to have multiple modifiers selected at once is absolutely necessary in my opinion, but what would happen if I have multiple selected and I add a new one? Will the selection be preserved and add the new modifier to the selection or will I have to reselect all of the modifiers again?
I think there should be an option to use either the list or the current way, preferably as a toggle somewhere in the modifiers ui on each object so that you can use the list with objects in the scene that have enough modifiers to justify its use, or the current way for objects that don't. There should also be an option in the preferences to set the default view type for new objects.
Having worked with super long modifier stacks in the past, I would really welcome this change! But It should indeed be possible to display a selection of modifiers for easy tweaking of multiple values.
One of the problems I see potentially is when the area becomes too small and/or a modifier panel is too long: When you tweak a value all the way to the bottom of a panel and you want to jump to another modifier, you would still need to scroll all the way back to the top to reach the UI list. A solution to that could be to leave the list on top of the area at all times and the panels (see attached scribble) but perhaps this creates new issues.
Another thing that would cause lot of scrolling is if you have more modifiers than UI list can hold without expanding, so basically more than 4. Let's say you have 8, once you tweak 8th modifier and want to get to 2nd, you not only have to scroll up in the properties, but now you have to scroll up in the UI list too.
Lot of scrolling is unavoidable when using many modifiers, and I think this design while has it's benefits will introduce bit more scrolling, or shrinking usable area for properties. And if we have to scroll no matter what I prefer current design much more, rearrangement is easy as hell, you can also hold LMB and collapse or expand every modifier with one stroke, which is genius UI.
I think @Nika-Kutsniashvili has a point. Especially since the size difference between the collapsed modifier panels and the list actually isn't that much.
Here's a comparison using the default layout on a 1080p monitor:
So in terms of space I'm not sure the list really is an improvement.
I think issues with the modifier management could be improved by building on top of the current panel concept.
One small thing could be a shortcut to collapse all panels (rather than all but the current one) to quickly get a "list like" overview of all the modifiers.
For the use case where you have a few, far-apart modifiers in the stack where you'd like to tweak values simultaneously, I'd rather see a "Filter Modifiers" popover to temporarily hide a few modifiers. The filter concept is already familiar from other regions and as a popup it wouldn't compete with the space used for interacting with modifiers.
Quick mockup to get the idea across:
Just a suggestion/idea, how about an option to star your most regularly used modifiers and have them appear in the Add Modifier dropdown without having to navigate to a second layer of a menu? I'd estimate about 90% of the time I go to the Add Modifier menu, it's to add one of about 3 or 4 modifiers I use on just about everything.
I don't think this is a good idea. These types of ideas almost never work in practice because you are making UI to manage the UI. Last thing people want is to manage the UI itself, instead of managing the factors that actually affect the art. With this popover, instead of managing the modifiers, you'd manage the UI that manages the modifiers you want to manage. It's extra step and extra mental burden.
If we are trying to solve the problem that modifier panel contents are often too complex, adding complexity to the modifier panel by introducing a popover which requires a mouse click to reveal will hardly solve that.
I am a fan of the list proposal in the original post for these reasons:
Your popover tries to solve an invented problem, not a real one. It also doesn't make much sense to pretend like we worry about enough vertical space in the default out of the box Blender configuration. If we did, we'd never default to Outliner editor so short it can't display over 13 rows without scrolling, which is far below average scene complexity. So it's safe to assume users are used to scroll a bit.
And then you need to resize it again to access another modifier. And then make it shorter again. Then when you want to access another modifier make it larger again, and then resize...
I think we can all agree there are pros and cons. These kind of workflow changes need a working prototype to help clear things up (using the add-on is not a good option since it's quite bloated compared to this proposal).
This will be tackled once !110828 is in.
You can scroll…
You don’t make your material panel longer to see more materials, do you?
You can scroll Properties panel too. If we have to scroll I'd rather not have ugly square taking up space that can be used for properties
I highly agree with this.
Lists are good for some cases, but not all cases.
the new Add Modifier menu is slower than the old version. I did add make an addon to bring the old version back, but I don't like it when I need to build a tool that the Blender team did change or removed.
The 2019 version is the best based on speed and design.
I don't like the new version, please devs, allow us to switch it back in the preference menu.
I agree with this, coming from a place of preferring speed over how "clean" the UI looks. While that is of course subjective, I am really not a fan of this proposal. A lot of the modifiers have already become taller, taking up more space, hiding more settings, and requiring extra clicks to get to them. To then now say vertical scrolling is an issue seems... a bit backwards to me.
Don't get me wrong, I understand what the intent is here. But I don't think more hiding and more actions to get to where you want to be (also leading to less discoverability) is the answer.
If I have 5 or so modifiers, those all fit just fine. If I have between 6 and 10, sure, the list might be faster. But any more than that and either 1) the list becomes painfully long, or 2) I now still have to scroll, just inside a little box instead of the whole area.
I understand this is all extremely subjective, but just wanted to add in my $0.02 as I really don't like this approach.
Though if we can select multiple modifiers at the same time in the list to display their settings in the editor, and why not have them all selected by default, that solves the above issue.
Edit: regardless, you can use Old Modifier Menu - Blender Market
The thing is this, why can't we have an option to revert to the old version?
The new version is less user friendly, slower and makes blender harder to learn.
And I know we can search, but if I don' know what the modifier is named and what category, then I need to hover over all the categories and find it, the old version has 1 click to open, and you can easily find what you are looking for.
Hi everyone, I would like contribute with the simple idea on add Modifiers menu.
Four buttons on top > when you click or mouseover, a submenu appears with list about the category.
I like this idea, but you need 6 buttons, the 4 that you have and 1 for the hair and 1 for new node tools.
But still, not allow the users to switch back to the old version is annoying.
@DeadDrag0 like this, with 6 buttons
if you like back modifier list, its possible with addon
https://blendermarket.com/products/old-modifier-menu?ref=2
Agree. Blender 4.0 add modifiers list is just bad and slow.
It benefits new users who will eventually quit blender mostly. Those who stick with it will appreciate the speed of the old system, and those who are regular blender users already do.
I wish they would undo this change in 4.1 l. It's very bad UX practice IMO. The search function is great though, but no reason that couldn't have been integrated with the old add modifiers list instead of this new albatross.
Sticking with 3.6 LTS or the old modifiers menu addon for now, this is a change that currently prevents me wanting to use 4.0.