This is truly the new modifiers list?
It have same problems, or worst, that actual system. Why not do something similar to “modifier list” addon?
7 Likes
Nope, it the actual modifiers tab in an official branch.
No way. 
I still can’t believe. I hope it’s just a work in progress.
Omg!..please go for something like modifier list instead
It looks broken now, but if you look closely you can see what you can now drag’n’drop modifiers to change their order, no need for old clunky arrows.
It’s the most top requested feature on rcs: https://blender.community/c/rightclickselect/fbbbbc/
- Ability to use drag and drop to re-order modifiers and constraints, rather than pressing little up/down buttons many times
- Ability to use sub-panels within large modifiers especially
- Ability to use consistent layout with the rest of Blender, including decorators for easy keyframing.
5 Likes
Y tho…?
I mean if modifier nodes are are the first thing on the list of going node based, why make cosmetic (not functional) changes to something that will have to be deprecated soon anyway?
The Drag&Drop is not the problem, is the general design. It’s harder to read than the actual design or like the modifier list addon. Or that it uses excesive subpanels way making it difficult to use them and needing more screenspace to show the same. for example, the edge split modifier have a subpanel only for one value. We have a lot of complains about that layout in 2.8
2 Likes
This will be used for constraints too, which will take much longer to convert. Even geometry nodes may start alongside the modifier list, and only fully replace it later.
Thanks for the info 
On one side, text is a label. On the other side text is name of setting.
To me, that looks like less confusing choice if you want to adopt one column concept to modifiers.
In that case, continuing to add label in a row on top would result into a too long column.
IMO, a modifier’s list is redundant.
Imagine that you want to tweak a Weight Group modifier that modifies weight of a vertex group used by another modifier ; at same moment, that you set-up that second modifier.
If you want to tweak 2 settings from 2 different modifiers, you will still need to display 2 panels with a meaningful header for each.
So, you have 2 rows in list and 2 rows to name those panels.
Instead if you have buttons like in modifier tools addon to close all modifiers, closed modifiers are not taking more space than list and you gain 2 rows.
And we could have display settings to show only open modifiers and replace a multitude of in between closed panels by a line.
+1. A sub-panel for one value does not make sense.
I can understand the will to hide an array.
But when modifier is only made of 3 settings : user who will want to gain space, will simply close the entire modifier panel.
Here, we have 2 boolean and 1 value. Use of Boolean options is not something that requires minutes of thinking.
If user is not sure about a think and will take time to tweak, evaluate that will be the numerical value.
So, here, what is hidden in a sub-panel is what should be exposed during most of time of setup of modifier.
1 Like
With the new system if you have open a bevel modifier it’s hard than any other thing enter in the properties panel. It’s more easier use a list like modifier addon which has been a great success among users. More if you try to work with 5 or move modifiers.
I am downloading sources of branch. I would make a more in-depth feedback, later.
Bevel modifier is already the longest modifier in master.
I can’t imagine that use of subpanels for it, will make it longer when they are closed.
Anyways, you can’t use that specific case to explain that being able to tweak 2 different modifiers is not efficient in many cases.
For example, to adjust a generate modfier to a deform modifier.
You have to constantly click on the list when using modifiers list addon. It is not efficient.
Reality is that dragging of modifiers is a more popular request than a modifiers list (mainly popular because it reminds 3DSmax to new users).
Are you kidding me? This is the most confusing ui layout ever.
The only good thing about all of this is the drag and drop feature.
We should consider the changes done here as experimental, some (possibly all of it) may not turn out to work that great and there will have to be compromises. In fact there always are compromises to make, hence the experiments.
There is a bit of context to note here:
- Regarding sub-panels for single values –
William and I have been working on general changes to checkbox layouts (see T65965), part of that is addressing this issue. We now support these kinds of layouts, which would be used commonly: I think the modifier in the branch just wasn’t updated yet. - AFAIK the changes initially included a
UIListfor modifiers, like the Modifier List Add-on. But having both, a list of modifiers and the entire modifier stack with draggable boxes was rejected for the obvious redundancy, we need to take one or the other. I think it’s a subjective matter of what works better in practice, so I don’t see an issue with keeping the option for this via an Add-on. - For me, an important criteria for accepting these changes is that the panels make it clear that they are not regular panels. So the panel drawing might have to be tweaked to look a bit more like the old modifiers. This is being discussed currently, e.g. William made this mockup:
That has big impact on the readability I think.
12 Likes
After browsing all modifiers, here, are my critics and suggestions about current status of branch.
Data Transfer : Exposed settings are not the most important ones.
-
In master, Max Distance is greyed out by default. That is an advanced option like restriction to a vertex group.
Both settings and Ray Distance could be into a subpanel labelled advanced. -
Main settings are into subpanels precising data to transfer.
That does not make sense to add a Vertex Group subpanel into Vertex Data subpanel.
Layer settings could be greyed out if Vertex Groups button is enabled.
I would prefer simply to hide options when it is not pertinent. But it is not guideline.
It is true that situation is different in Face Corner Data. It is necessary to distinguish Vertex Colors and UVs settings when both are transfered.
Mesh Sequence cache : Subpanels don’t seem useful at all.
-
Except Apply and Copy button, all settings are under 2 subpanels.
So, when you add mofifier : all pertinent settings are hidden.
3 lines are displayed but that is as informative as if modifier is closed. -
So, if first subpanel is removed to keep only second one. That is a subpanel just for 1 line.
That is a riduclous gain of space compared to closing the whole modifier.
So, none should be kept.
Normal Edit : Here, again. What is exposed is not the most important.
- It is easier to use an object as a reference in Viewport than tweaking offset values.
- And Mix mode, hidden into subpanel, is crucial.
I would rather put Offset into its own subpanel with vertex groups ; and put back Mix mode,Mix factor and Max Angle as basics of modifier.
UV Project : Projectors list may be increased by user.
That may be useful to create a subpanel for that. But that is not frequent to use many of them.
So, if it is created, it should be opened by default.
UV Warp : Here, also, Offset, Scale & Rotation could be grouped into a Transform subpanel.
Most of time, 2 reference objects (From, To) are only settings precised.
Vertex Weight Edit : I understand that FallOff subpanel is there in case of Custom Curve use.
But for all the other uses, that does not make sense. It is one subpanel for one line.
That is why there is no such subpanel in Vertex Weight Proxility modifier.
Can’t it be possible to have a button to close Curve Widget, instead ?
Bevel :
Probably, Clamp Overlap, Harden Normals, Mark Seam, Mark Sharp options could be moved to Advanced subpanel.
But I would group things, differently.
- Mitter Types, Intersections, Clamp Overlap & Loop Slide into an Advanced Geometry subpanel.
- Face Strength, Harden Normals, Mark Seam, Mark Sharp and Material Index into a Shading subpanel.
Mirror :
- I think that Vertex Groups option can move inside same subpanel than UVs mirrors.
This subpanel could be renamed Data. - Clipping option can be used enabled without merge enabled.
It should not be placed under the same panel but took current position of Vertex Groups option.
Multires : That design is not functional at all.
It lacks of several essential of modifier. I suppose that should be completed.
- I would say that Quality, UV Smooth and Use Creases could be put inside an advanced subpanel. Optimal display as a frequantly used dislay option should not be inside a subpanel.
Same remark is valid for Subdivision Surface.
Skin : Interesting arrangement of buttons. Why not doing that for multires ?
Solidify:
- I know it will slow down usage. But maybe, it could have a Normals subpanel like Screw.
- Fill Rim, Only Rim, Clamp, Angle Clamp and Vertex Groups lines could be inside a unique Advanced Geometry subpanel.
Wireframe : 2 columns + decorators are making names of options unreadable.
You could keep a unique Advanced subpanel and put Even Thickness, Relative Thickness, Vertex Groups and Crease lines in it.
Shrinkwrap : For Project Wrap Method, there could be a projection subpanel to include settings added by method.
Simple Deform : Although that is a coherent grouping, Orientation is a crucial point for this modifier. It can’t be inside a subpanel.
I would rather group Limits, Vertex Groups and Locks into a Restrictions subpanel ; and let Origin and Axis exposed like Angle.
Wave : I don’t understand why same XYZ buttons as elsewhere are not used, here.
Unfortunately the branch wasn’t quite ready for this sort of feedback before it was shared. That’s why there is so much of this kind of feedback to give! I don’t think William or I have fully gone through all the modifiers to iron out issues like this yet.
That said, this is the sort of feedback that’s actually very helpful.
Data Transfer
That seems to make sense.
In this situation I preferred to be consistent between vertex data and face corner data. Although like you say it might make sense to just hide the vertex group settings.
Mesh Sequence Cache
Master puts each of these in a box, and as I hadn’t used this modifier before I figured there might be a good reason for this. I agree though, subpanels don’t help.
Normal Edit
Offset in a subpanel: seems to work
Maybe mix mode could be in the header of its subpanel. I’ll have to try out your suggestions here.
UV Project
Not sure a subpanel for projectors would help here if it’s open by default.
UV Warp
Agreed.
Vertex Weight Edit
It’s out of scope to add a close button to the curve map widget. Maybe putting the falloff type in the subpanel’s header would help. Although as that’s not done anywhere else it would need buy-in from other UI developers.
Bevel
I like your proposed grouping. I’ll try it out.
Mirror
Agreed.
Multires
You’re suggesting adding a subpanel for those three options? Keep in mind that would be below the operators.
Two buttons on a row might work here. We don’t want to cram stuff too much though.
Solidify
The main constraint here is the large difference in options for the two modes. A normals subpanel might help though.
Wireframe
The two column layout is supposed to be a “flow” layout that expands to two columns when it gets wide enough. Looks like it’s not working though.
Project
The issue is that none of the project settings apply for other modes. I’m not convinced a subpanel for it is helpful.
Simple Deform
I like the idea of a restrictions subpanel.
Wave
I suppose so the decorators can show up? It might be better like you suggest.
2 Likes
I’ll have to reserve most of my judgement until when it becomes a bit more finalized, but, I agree the “wide” view that was posted by op wasn’t a good first look. Things look a bit better when using more narrow layouts but it’s still not great right now.
A few other pieces of concrete feedback:
-
The toggles for the modes are listed as [cage/edit/viewport/render]. How about re-ordering? I would suggest either to use the existing order of [render/viewport/edit/cage] or [viewport/render/edit/cage] the latter of which would align with how the Outliner displays the viewport and render filters.
I know you’re trying to keep the icons aligned which is definitely nice. But you can keep them aligned the re-ordered way too. Just pad with an “empty” icon space to the far right if the edit or cage options are not supported for the current modifier.
-
Single column layout. I get it, you want layout consistency. But this is instead resulting in complete visual inconsistency; and the tradeoff here is often not user friendly or aesthetically pleasing.
-
The biggest downside to single column layouts (in any UI) is when items in the layout are of different types. Single column layouts only really work when there are sequences of several items, of the same type, and they naturally group themselves. Take Decimate as an example. There’s a dropdown, a numeric input, a checkbox, a free-form input, and a text label… 5 different items all stacked on top of each other each with different styles. This doesn’t work very well in practice I think. There might be some modifiers where you could attempt to mitigate this but not in general. It would mean grouping similar items, perhaps in odd ways, to achieve a good result. Not sure what to do really.
-
The single column layout wastes too much horizontal space. The modifier pane will often live under other regions, like the Outliner, that are more naturally wide. Let the modifier pane take advantage of the horizontal space better. It’s already an absolute pain to keep modifiers tidy since they are already vertically so long. Don’t make the problem even worse.
-
The space issue is compounded by now forcing some options into subpanels that require expanding/collapsing. The management of the expanded/unexpanded panes is part of what makes working with modifiers so tedious now. I don’t think adding more panels is going to help much; especially if the modifiers with those subpanels are already so long that scrolling will no doubt have to occur anyhow.
-
-
I too would like a “modifier list” if anything drastic is to be done with the modifiers in general. Sure, we might get drag/drop of modifiers to change their order now, but I’d rather see the UIList widget get that instead, which would benefit many other places in the UI. I would much rather have a central list at the top, supporting drag/drop of items, while only displaying 1 active modifier below the list; though that’s mainly personal workflow talking as I rarely need to edit 2 modifiers simultaneously and if I did, I’d still prefer the list
1 Like
I thought about the length it takes when several projectors are used. But you are probably right. User sets that, once and then, you close modifier.
I would not mind.
Yes. Same as UV Project. Most of animation relative to modifier is probably happening in Viewport.