Modifiers UI
Open, NormalPublic


Blender includes a powerful modifiers system for non-destructive editing and effects.

The Issue
There are a number of issues with the way the current modifiers are displayed currently:

  • Reordering modifiers is not efficient or clear (the buttons make the modifiers instantly jump, and it's a hassle moving modifiers many steps at a time)
  • Modifiers jump instantly when reordering (This may seem like a small issue, but reordering quickly becomes unclear because things move instantly. You loose focus on the item you're interacting with. )
  • The order of evaluation is not clear (In Blender, it goes from top to bottom, but it's not communicated at all)

Proposed solution

  • Reorder modifiers by dragging them. This is much faster when moving them more than one step, and it's way clearer
  • Modifiers should move smoothly out of the way when reordering (clearer)
  • Add a > shape to the bottom of the modifiers to clarify the order of evaluation

Re-ordering modifiers:
(click to play)


There are a very large number of changes, so older changes are hidden. Show Older Changes

@William Reynish (billrey) - the nodes already to that don't they? the settings of the selected node are displayed in the properties panel, or were you talking about a proposal for the materials tab in the properties editor?

any way, for the modifiers,the extra click seems justified in light of clarity it brings to the modifiers pipeline - consolidating the physics and particles panels as well.
If the user wants to display more than one modifier, control clicking one two or more,or control+A to select them all would display them as desired.

These are all so good suggestions, hard to decide which one is more awesome.
Here some points:

  1. Dont know if this is important: You can hit more than one button/arrow at once by holding mouseclick and dragging the mouse over them. Placing the eye-buttons in line under the little arrows makes it harder to activate/deactivate in a row, because it would trigger both when you pull the mouse straight down.
  2. Though, the long header is very useful for oneself to add some short information. Can you make the panel background for the second line the same color as the name header? So it looks more related on long modifier lists. Wanted to try by myself, but my image editing software was not talented enough.
  3. Dont we need order-buttons to imply that you can order modifiers at all?
  4. Is it possible to make the tiny plus for add modifier react to the whole line for mouseover? I think this would be more comfortable for a rather important button.

But to be honest, i would like to see Blender stay with these big named buttons for "add new" as it is instantly clear what they will do. Plus (:D), they are often used.
Expanding to materials, you wouldnt have the extra click for the slots. (I dont really know where they are in use other than for offset material)

To keep things consistent, whichever UI solution is decided on for the modifiers tab, would have to be made for object and bone constraints as well. Contraints have a similar look and behaviour as modifiers, where order of evaluation is important, you can collapse the panels, toggle effect on/off etc.

Would be weird if only one of these got an upgrade and the other left with all the problems described in the original proposal.

@William Reynish (billrey) thanks for doing these designs and proposals. I'd really like to get this tackled in 2.71.

The first thing I'd like to see tackled is Drag and Drop reordering support.

How about splitting the hair and particle systems into separate modifiers?
This could be done nicely with the list view proposal, and would make for a cleaner, more logical and discoverable system.

not sure if this is off topic or not, it seems like mostly a UI change to implement, but perhaps it would be a separate task.

Calling it "Copy" is sort of misleading since it actually duplicates the modifier. "Copy" would imply that you can later paste it.

Awesome! I've been hinting at UI-type developers for a while that drag and drop for modifiers would be great. Please don't stop here!
-constraints (very similar issues there)
-animation channels
probably could be something to think about for UI list type interfaces. The reordering is ok there but could be better still!

Love the idea @William Reynish (billrey) :) I totally agree that the current controls add clutter and disorientate the user when reordered.

However, I'm not entirely in favor of the proposed mockup, for two reasons:

  1. The little arrows pointing down, don't clearly indicate that one is above the other. It mostly just draws your eye to where the arrow points to.
  2. The visual indicators that they can be moved aren't clear enough.

I'd propose these solutions:

  1. The literal placing of one modifier over the other (with a subtle shadow) hints to the viewer of the order.
  2. A different symbol for reordering
  3. The trash can icon is used instead of the X symbol. This is up for debate, but I found it more consistent with current UI symbolism (literal 'trashing' of a modifier).

Version 1 - 3 dots for reordering. Common in apps like Gmail).

Version 2 - 3 bars for reordering - Used in most iOS apps

Version 3 - Ribs. Standard in many software like Photoshop.

Which do you think best symbolizes reordering?

Personally I feel like the arrows tell me more than the drop shadow; the latter is quite unclear to me, chiefly because it is so unobtrusive I would hardly notice it!
As for the reordering icons: from the number of different ones you suggest I guess there's no 'standard' way to represent this. They all don't communicate 'reorder' to me at all. However, if Blender picks one of these or a different symbolism for reorder, it should be consistent everywhere there is drag and drop reording so people only have to learn it once.

Version 3.

Because 1 and 2 is dangerously close to the delete-button. x(
X/Delete in distance to all other buttons should always be a point to be aware of, but its indeed rather difficult here.

But now i think billreys arrows which leading to the result seem quite suitable for this case as long as the "result" text would make it to the list. In my early blendering it took me a while to understand that modifiers dont work simultaneously - its a good help.
And to change the order means to change the arrow line so i guess it makes sense to click on it, even for newbies.
Maybe more button like or ripped, yes.

on further reflection, looking back at billrey's original mockup (and yes this is subjective) the 'window' design with a header is very communicative of dragability. I've seen websites start to use this, and it feels more familiar than the tiny little icons. I'm really not used to clicking on tiny little icons to drag windows/areas around.

version 3 is a nice visual indicator of a handle, without being too obscure or hard to grab.
its also consisten with the drag indicators in the new list boxes(two lines)

I prefer the arrows. I remember them from a "visual programming" app from OS X (not sure if we are allowed to mention propietary apps?). It always made sense to me, one thing feeds into the next.

On dragging, there's no need for icons. Dragging from the title is the standard way to do it, specially for creative software. For instance, the panels in GIMP and Inkscape.

@Warren Bahler (russcript)
Actually that may be an argument against using that symbol, since they perform completely different functions and would therefore confuse users.

@bassam kurdali (bassamk) & @Diego Gangl (januz)
That's true, draggable headers/titles could definitely work. But we need to consider that outside of this thread, blender users won't know that we've made this decision. For the last 4+ years modifiers have been arrows. Adding click+drag functionality with no visual indicators would cause frustration and a learn curve for current users.

However we could work around this with responsiveness. Some ideas:

  • When the mouse hovers over the modifier header, the cursor could change to a hand icon, indicator that an action can be performed.
  • When clicked and dragged, the icon changes to a grab icon, which tears the modifier header to the mouses movements, indicating that the modifier can be moved.

@Andrew Price (andrewprice) Yes, changing cursors is a great idea. I'm not sure about that hand icon, because it's used to represent links. I think the open hand cursor would be better, and then the grabbing hand when dragging.


This is quite similar to existing suggestions. I have tried to make a few additions.

  • Buttons for "Apply" "Apply as Shapekey" and "Copy" were removed and replaced on the top.

Arent necessary in every single modifier - the list is shorter/reduces scrolling.

  • Suggestion to select modifiers via highlighting. Similar as in 3D-View, same actions are allowed. Like multiple selection and delete/grab/duplicate/copy-paste to another model and hide/unhide at once.

I think the highlighting implies for most users it can be moved. The mouseover cursor-change is just as good.
To Apply a modifier, select it and press the button on the top.

  • Scrollbar/window dont scrolls "Add modifier" and the replaced Apply/Copy buttons - only the modifier list.

Also reduces scrolling in long lists.

  • Eye-symbol goes to the right - Symbols build up to the left to keep all symbols on its place/line for every modifier.

The space on the right side makes it easier to see if its enabled or not and safety distance (X) is created. (i think the eye symbol is used more often)
You can click on one eye and drag the mouse over other modifier-eyes more easily.
Editing Cage symbol dont displace the eye-button for example in Subsurf modifier.

Good ideas, but I think the most elegant and fluid solution is still the list box header; this could could effectively extend the concept of placing all the 'global' buttons and settings at the top, thus unnecessarily reproducing them on every modifier.

Plus the additional benefits of reducing the number of tabs in the properties editor, and consolidating the physics into the stack properly, which may become even more crucial in the future with the more integrated (layered) physics planned.

Are there any serious cons with the listbox proposal? It seems to me to have many more pros than cons, but that's totally open to discussion.

To combine the physics, particles and modifiers panel for a unified "pipeline". Now that would be nice.

Here is my rough proposal.

Ok guys, I hacked together an addon which demonstrates the list box UI in limited fashion; the main limitation being that only one modifier's settings can be displayed at once, and I couldn't (easily) implement every physics type (Particles,Force Field,and Rigid Body).

The reasons for this being that I don't have the python experience necessary to get everything working, but for the most part it's a good test of the concept.For now the modifier settings are displayed as regular panels and not modifier_template boxes.

to install the addon :
1.copy the file below to : ....Blender\2.71\scripts\startup\bl_ui (overwrite existing, this moves the existing modifier stack to the object properties tab,make a backup if you wish)

2.(re) start blender

  1. install the addon and test :)

@Warren Bahler (russcript), that's really quite nice. But I have one main concern. Using the UI List Box the concept of top-down is lost, where the modifiers are applied from top down, each one affecting the modifier(s) below it. Granted, this is not clear in the current situation either, but I think it's an issue that should be addressed with any Modifier redesign. This issue was elegantly addressed in @William Reynish (billrey)'s mockup

Modifiers are different than say materials, since the order in the list is vitally important. Materials, textures, and other things don't care what the order is in most cases.

I am in favor of drag and drop.
Probably, it implies more than one modifier selectable at a time.
Maybe, they could be selectable with border select B like in outliner and right click could be used for several actions (move, apply, copy, close, expand).

For readability, I'd rather the simple solution to keep one line for the close/expand icon, the descriptive icon, the name/label, using during render icon, display in viewport icon and the delete icon.
Another line could be dedicated to other action (display in edit mode, adjust edit cage, copy, apply, apply as shape, copy settings, paste settings, link or wathever new ability that future would add to modifiers ...). It would be hidden when modifier is closed and just this line could expand on mouse over.

I like the listbox approach in @Warren Bahler (russcript)'s add-on, because if you have a lot of modifiers or a modifier with a lot of settings (ocean for example), it keeps everything tidy and avoids being a scrollfest. Layer systems in graphics applications typically use a listbox to manage them and they're top down, so I don't follow why the top-down concept would be lost; perhaps I'm misunderstanding what the concern is though. Listbox or no listbox, I definitely would prefer drag and drop for sorting.

@xrg (xrg) the listbox is nice and clean. I like it a lot as well. My concern is just that it doesn't clearly indicate to ignorant users that modifiers are applied top down. If listbox can be tweaked to describe this more clearly then it may work very well.

+1 zeuro's comments

I'm not *initially* convinced by a listbox;

  • they can become awfully cumbersome and have unneeded nesting (box within a box)
  • they have a 'nested scrolling' issue when you have too many items.

They work well when:

  • you have under 10 items or so... :
  • and when you only expose one or two properties in the list box
    • and when you need to share space in the space with other property buttons (box in a box) ( for example I'm using them for a scene layer manager and it already becomes a bit annoying with 20 layers )

      For reference, gilgamesh from tube has 74 modifiers on her head/arms mesh, fewer on other parts of the character.

I also like the idea of being able to ctrl click the arrow(or some other mechanism) similar to Panels, to 'solo' a modifier UI and collapse the other ones - should help with really long stack.

Finally, it would be amazing if modifiers and constraints both 'went' towards a nodal system - meaning a node editor that had modifier nodes of some sort. I guess this is out of scope of the current UI design, other than perhaps thinking about how to preserve a stack UI - similar to cycles - for those who don't want to use nodes.

@Jonathan Williamson (carter2422) - But I have one main concern. Using the UI List Box the concept of top-down is lost, where the modifiers are applied from top down, each one affecting the modifier(s) below it.

This is a good opportunity for me to mention something.

All calculations in Blender are made from top to bottom - that includes Modifiers, Textures and Nodes. This is logical - code is read from top to bottom, so the thing at the bottom will be fired last.

But is it?

It is when we think code-wise. When we think in terms of metaphors - not so much. A metaphor usually used for effects in interface design is that of covering. You have your base object, and then you cover it with effects (that would be Modifiers). You have your base image, and you cover it with layers (that would be Textures, Nodes dealing with images, and maybe someday true image layers).

The top-down system doesn't bring any advantages that I can see. On the contrary - it causes problems. When you connect an image node over another image in the Mix node, it goes under that image. So you have to connect it like this:

When you have a half-transparent decal texture, you have to put it under your main texture.

Will we keep this convention when image layers come in? I don't think so.

So. I like the idea of Modifiers using the list system, if the list is fired from the bottom to the top - so you can for example add a Subsurf over all your other modifiers, not under them. No arrows would be needed then.

With a list, the modifiers can benefit from all the upgrades all the lists in Blender get - double click to rename, search, maybe drag&drop? And the combined Physics, if that's doable.

Hope that makes sense. Tell me what you think.

Diego Gangl (januz) added a comment.EditedJul 24 2014, 12:27 AM

I'm starting to lean towards using a UI List for two posibilites: searching and filtering. You could use naming schemes for modifiers and then use search to filter them. Filtering by type could be added too. That could solve any scrolling issues.

I can't think of any elegant way of communicating top-down in the lists, but it's one of those things that once users know it, don't need to be reminded of.

Finally, it would be amazing if modifiers and constraints both 'went' towards a nodal system - meaning a node editor that had modifier nodes of some sort.

Lukas Tönne started working on something like that some time ago:

I think full nodification is still far away though.

@Jonathan Williamson (carter2422) -Thanks for the feedback, I agree with the concern about the "top down" being clear but as @xrg (xrg) mentioned, many applications use a layer system that processes top down, so the concept is quite familiar to most's also an option to add a UI element (such as an arrow) that indicates the sequence order.

@bassam kurdali (bassamk) - True, many items in a list-box can be cumbersome, but is it more cumbersome than a long list of collapsed modifiers to scroll past to edit another?
also, as @Diego Gangl (januz) mentioned the listbox can be sorted and searched, which could greatly help with managing large numbers of modifiers

I'm not suggesting that the list-box is 100% perfect, but in practice, it solves several other UI problems/anomalies in one blow, for instance: - the confusing dual naming of particle systems, the placeholder modifiers for physics, the way multiple physics type's panels on one object run together with no visual distinction, the width of the properties tabs being rather wide.... and so on.

listbox might have some good features, but I think this is not about just changing modifiers to listbox; rather we're talking about design.
Therefore, instead of talking about 'listbox' which is an implementation, the focus here is on the design. How it is implemented can be a later step.

That's my opinion anyway.

So features of the design you want could be:

space saving
search and filter. (for example)

I can't think of any elegant way of communicating top-down in the lists.

max displays an alert of you touch a modifier beneath the last one that can change the result, but it uses modifiers as a history record nothing more.

i think you can take color to communicate functionality, like red out the above modifiers (indicates that it will recalculate) and green out the below ones (indicating it has been already calculated), maybe!


@bassam kurdali (bassamk), right, this does'nt need to be focused on the exact implementation, but the listbox in already a major feature of blender's UI, and would be consistent with many other part's of the interface. Not to say there isn't a better way though.

as far as communicating the 'top down concept', I'm not sure if it's as big of a deal as were making it - as it's a convention used thru-out the interface, the user will have to learn it anyway, and it's not a difficult thing to remember. In other words, I think functionality,and better integration of the interface is the more important issue ATM

The top down has it's own issues. It would be nice if it would work in all cases but see fluid or multi res modifiers. They always stays on top. Hope that made sense.

I agree that dealing with a long modifiers stack add a scrolling problem.
But if you have only 3 or 4 modifiers on most of objects of your scene, a design with a listbox will still use panels with titles and listbox will take extra space that would be resolved by an extra clicking problem.
bat3a 's mockup show it; only one cloth panel is open.
If modifiers become selectable, a solo mode could probably exist for people who want only one modifier open.

Since the first 2.5x design, I believe that Properties editor should be splittable in 2 or 3 columns.
Tabs resolve problem in toolshelf but not for modifiers or particles tab.
In fact, panels were splitted in two columns. It makes a Properties editor taking the whole height of the window able to display 5 ,6 panels or 7, 8 (if you zoom out).
So, with a larger space taken by Properties editor splitted in 2 columns, double of modifiers could be seen in same time.

Sorry for uglu mock-up. I did it quickly.

Current filtering by name does not make really sense for modifiers. I am not sure that filtering by categories make more sense except to distinguish Simulate modifier of the other categories.
But it is already done if we use physics tab.
I admit that I would prefer a listbox in physics tab instead of current buttons. In this case filtering by names make sense for caches, domains or physic type.

@Paweł Łyczkowski (plyczkowski) Reversing the stacks is an interesting idea. My only worries would be old tutorials and performance when flipping a +70 stack.

@Yousef Harfoush (bat3a) The problem with using colors is themes, the background of the box could make those unreadable. And if they can be themed, the meaning might be lost in some cases. Also, red usually means error.

Here's a crude attempt at bringing back the arrows while staying out of the way:

Current filtering by name does not make really sense for modifiers. I am not sure that filtering by categories make more sense except to distinguish Simulate modifier of the other categories.
But it is already done if we use physics tab.
I admit that I would prefer a listbox in physics tab instead of current buttons. In this case filtering by names make sense for caches, domains or physic type.

Physics are modifiers too. With the listbox particles and physics could be merged into the modifers tab.

Searching makes sense for large stacks. You could have several particle systems and name them like:


When you need to tweak hair in your character, you can search for "hair_" and see only what you need.
It's a little more annoying when working with few modifiers, but I think it's a fair trade-off.

Physics are modifiers too. With the listbox particles and physics could be merged into the modifers tab.

exactly, and note that the particle system already uses a listbox, and the physics tab really should use a listbox, because if you add multiple types of physics, you end up with a massive list of panels running together with no separation. A listbox would actually be more compact that the panel of buttons currently used for physics.
Which in turn points to the obvious (imo) solution of combining all three tabs into one.

My main problem is that when you are animating with particles you also need to tweak animation of geometry and physics.
I agree it is not possible to see all theses panels in one vertical column. But I bought a wide screen and now, I have dual screen.
I want to be able to use this space to avoid constant clicking,
So, I create a screen displaying 3 or 4 Properties editor showing all these panels.
Currently, several properties editors are able to display different tabs.
But these editors are not able to display same tabs with a different content.
They only can do it if datablock is pinned or for textures tab that have context subtabs.

I am saying that a listbox implies bigger changes in UI that just modifiers tab changes.
I would prefer a properties editor with 1 listbox that can be extended to 3,4 columns than 3 or 4 properties tabs showing 3 or 4 listbox.
It implies several little changes also for every feature that use particles list index, renaming for option Use Modifier Stack.
But fusionning 3 tabs in 1, is not a little change. If there is no work to assure compatibility with a 3 or 4 column layout, it will impact UI flexibility negatively.

For the record, I am against "just using listbox" as is.

For the reason Zeauro mentioned above (very roughly): sometimes you need/want to see more than one thing at a time. Listbox is not handy for this: you either Jam so much stuff inside one line, resulting in a cluttered mess, or you can only view the buttons for one modifier at a time. Listbox is a cool UI element that could be used more in blender (maybe for background images?) but not here.

Better to say what you *like* from listbox, rather than just blindly rushing to an (imo) incomplete implementation, that does not really solve the problems billrey's original and rather brilliant mockup does.

Zeauro's issue has popped up for me and could be something to consider (I haven't had the problem of trying to edit modifiers on multiple objects/contexts as much, so pinning has worked for me mostly. I work on either a dual widescreen desktop or on a widescreen laptop, typically)

The biggest positive change from Billrey's mockup is drag and drop reordering (everyone) and stack order visualization (new users) I think adding a 'solo' modifier when clicking on the expand/ contract arrows (i.e. ctrl click hides all other modifiers) and perhaps a search tied to that (though this could even be an addon on the current UI) would add most of the benefit from listbox implementation. I don't see how filtering is useful in context of the modifier stack though. Visualizing recalculations with color is interesting, however, it feels a bit redundant (this is mostly handled by stack order) and potentially an issue (lots of color in UI, color blind safe colors, etc).

If you were to add a solo modifier, how would that work if the modifier is in the middle of the stack? Would you literally only view that modifier or would you view only that modifier and above?

Rather than typing, I just made a video overview of why I think the listbox approach is better:

Nice ideas! Let's give some love to the Modifiers UI!
I had some ideas reading yours, plus mixed some things with your ideas, so here they are:
To explain the images: Instead of having the "Apply" and "Copy" buttons(The latter, in reality, duplicates the Modifier as noted by someone in the conversation), we would have a menu providing the available options regarding that specific modifier + some additional default options. The "Copy" in this menu copies the Modifier's properties and the "Paste", of course, paste properties copied from another modifier. Here we have the "Duplicate" which does exactly what the current "Copy" does: duplicates the modifier. Also, some additional stack-related options would be available to facilitate moving the modifier to the bottom or to the top of the stack.

In this design you would be able to see much more of the modifiers' names and would also be able to have bigger names. The names would be only editable when "Ctrl LMB" or "Double Clicking" like you do on list boxes. This gives you even more space to grab the modifier. By the way, in this design you would also drag & drop the modifiers to rearrange them, like some other presented designs here and the cursor would turn to a hand when you hover over a modifier, so you know you can grab the thing.

We could also have a "Master"(Named "All" in the picture) which could have additional features to control all the nodes at once, like: Activate/Deactivate them all in the Viewport as well as during Rendering; Expand/Collapse them all; Delete them All; Copy them all/Paste them all into another object(We can't do that without an Add-on right now, if I remember correctly).
I'm pretty sure you guys can come up with nice additional options to this menu.

As a side note, would be pretty nice to be able to "Solo" a modifier by "Ctrl LMB"(or "Shift LMB" like GIMP) on the "Eye" for the Viewport and the "Camera/Render" icon for Rendering; and do the opposite as well.

The "Add Modifier" is placed in the bottom to make clear that a new modifier goes to the bottom(An animation here would make things even clearer) and that the bottom is the end of the stack.

The line crossing the modifiers in the back would provide the visual feedback regarding the modifiers' relationship with each other in a "waterfall" fashion; basically a 1D node representation. To clarify the direction right away, an arrow could be added(2# Picture). The arrows presented on the @William Reynish (billrey)'s design makes it appear a balloon to me, like the GTK3 Popovers and similar ones. So it seem to actually belong to the bottom modifier instead of pointing to that direction; do you know what I mean? Take a look at some examples:

Having a difference in values(lightness) between the modifiers and the background is very important, in my point of view, because it pulls the eyes' attention to the modifiers and also creates a much needed separation between the modifiers and the background itself.

Same idea but with additional arrows pointing down:

Additionally, could anything towards the line implying a direction be useful with the list box approach? Just a fast test without a clear direction:

What do you guys think?

By the way... Any news on that Modifiers node system people were developing a while ago? Oh! That sounded pretty awesome!

What if you numbered the listbox in ascending order? This will encourage the idea of priorities (#1 needs to be applied/is calculated first, #2 is second, etc). This would clarify the stack ideology while not hindering the effect of the listbox, as well as being much easier to code than a change to the listbox class itself.

Also, how about displaying all modifiers that are selected in the proper order with multiple panels?

Something like this:

blakenator: by 'solo' I mean it would just collapse the other modifiers (above and below) showing only their headers, and keep the selected one uncollapsed. Similar to how the panels work.

@bassam kurdali (bassamk)

Better to say what you *like* from listbox, rather than just blindly rushing to an (imo) >incomplete implementation, that does not really solve the problems billrey's original >and rather brilliant mockup does.

The reason I didn't include a lot of reasoning with my (incomplete test) list box addon is because the pros and cons have been exhaustively covered in this doc here; perhaps you missed the earlier post.

you could also watch the video above posted by @xrg (xrg)

the concusion of both of the above seems to be: The listbox could be slightly slower in the case of editing multiple modifiers(specific argument). But the beauty of it is that it brings logical order, compactness, speed and transparency to blenders already complicated UI(global argument): which in the end is going to be the most productive.

I am aware that any implementation is going to have some weakness; what I don't understand is the logic that says, while A,B,C and D are an improvement, but because E is not, then the whole idea is a failure.

in any case, I'm not going to continue debating the subject - its not my decision anyway, just wanted to present it as clearly as possible so the UI team had more than a mockup.

@ russcript

I am aware that any implementation is going to have some weakness; what I don't understand is the logic that says, while A,B,C and D are an improvement, but because E is not, then the whole idea is a failure.

I think that bassamk conclude that listbox is out of scope of this proposal because everybody agreed that it implies a merge with physic tab which goes beyond original proposal.

I agree. it is up to dev in charge of this proposal or to UI team moderators to say if they want to just improve current design or to change more in depth how blender works.

Here a concrete case.

A particles emitter, a floor on which particles are falling and colliding with and a force field for Wind.
Same case can be valid for rigid bodies, sofbodies or cloth.
With current design, I can see what will influence particles movement without clicking on anything (except settings).
To be quick; I did not represent a deformed emitter but defrorm modifiers could be displayed in a third column.

If you suppress physics tab, where is the place for Force Fields and Rigid Body Constraints that are not modifiers ?
What is the behavior of listbox when you need to pin data ?
Maybe suggestions to these questions can be added here; I don't know. It is a decision that belongs to an UI team official member.

So I've read the PDF, and I feel that the main problem it is trying to address is bringing physics panel inside modifier stack - but it compromises the modifier stack itself in doing so (as it must - everything is a compromise)

The result is actually harder to use if you don't use physics; instead of one list, you have two lists, an outer one with a subset of the modifiers visible, and an inner one with it's own scrollbox. It is up to the user to understand which array modifier now is the one I've viewing, and if you have a lot of scroll in that box, you may not have visual indication.

So the result in my opinion: instead of really 'unifying physics/ etc' with the stack, it actually seperates every modifier out of the stack Even in the really common 3 modifier case you'll have this double stack.

IMO good UI should make 'simple things easy and complicated things possible'
The listbox solution is based on 'using what we have already' and not ground up enough, it ends up trying to simplify 'complicated things' but making simple things harder in order to do so. As you pointed out, physics and particles have so much settings that they are already really long, do we really want to tack a modifier list box at the top? I guess particles won't change in this case as they already have a listbox.

physics panel gets lonely a bit since somethings there aren't modifiers.... tricky.

My conclusion is that the original proposal is not so 'under the hood' but trying to make existing panel better. combining it with physics or particles should be a completely seperate discussion, and not hijacking this thread. My opinion only of course.

combining physics and particles into modifier stack: interesting but needs discussion first, a bit out of scope for this proposal- would like to see it in own task rather than piggy backing on this one.

Also how much of a problem is particles/physics tab really? while they can have modifier, it feels logical enough that they are in this place to me - are new users getting lost looking for them?

Rather than typing, I just made a video overview of why I think the listbox approach is better:

Thanks for doing this video @xrg (xrg), that really helps to illustrate your points very well.

Physics Modifiers are out of Scope

I'd like to ask that we keep the Physics modifiers out of this discussion for now. Yes they have problems. Yes there's good arguments for merging them into the regular modifiers panel. But that's out of the scope of this. Let's first address the issues with the modifiers panel, then we can improve individual modifiers that need it.

Moving Forward

If any one else has any other thoughts to add it'd be great o hear them. At this point I feel we have enough back and forth to at least make a decision to implement (or not to implement) one of the proposed designs. We can always keep debating (literally) but there's lots of progress to be made and other tasks to attend as well :) Now is the time to add any last thoughts if you have them.

Here's my comment, building off the original proposal and some of the comments so far:

  1. Single biggest improvement (and imo, single biggest problem with current modifier stack) is the drag and drop reordering. This will save so much bother.
  2. I'd like to see a way to insert a modifier in a single step right where it should be:

When we add a new modifier it gets added to the bottom (and in some rare cases, the top) of the stack (visually) we then have the really cumbersome task of moving it in the stack. Billrey's proposal takes a lot of the pain out of that reordering.

Have a way to add a new modifier right away in the right spot; either by having an active modifier and then it adds right after it (I don't like this much) or a visual way using the cursor (my preference) For instance:

  • Hover the mouse in between two modifiers and press a hotkey, brings up an add modifier menu under the mouse and inserts a new modifier right there...
  • Ctrl click the Add Modifier button, pulls up a menu as now, but instead of adding the modifier , changes the cursor shape to have a small plus, allows scrolling to, and then clicking on, exactly where you'd like the modifier to be.
  • Modify the small arrow indicating the direction of the mockup to have a small 'insert' button, that inserts a modifier where the button/arrow was

@xrg (xrg) thanks for the video, some comments:

  • for me the biggest problem is not that long lists become scrolly (this is gonna happen) but rather that reordering is a pain in the....
  • drag and drop reording implies autoscrolling (not scroll.. scroll.. scroll)
  • I propose using ctrl-click on the modifier arrow so you don't have to 'twirl things down' one by one, and you get better informational compactness than a listbox because you keep one list. (not two lists that are linked by what is selected in one)
  • drag and drop reording inside a listbox suffers from the same problems drag and drop reording in the stack would, except worse: because the listbox is so cramped you end up scrolling more
  • I'll re-iterate: listboxes create a congnitive load: you now have to associate some buttons outside the list, with what is in the list active. This still confuses me today with the particle settings, where some settings pertain to what's in the listbox (particlesettings) but a few don't. With modifiers, you might get things like 'adjusting settings for the wrong array modifier' from advanced users and 'can't find settings for my subsurf' from some new ones... especially since most people don't tend to name their modifiers.

positive comment:

  • listbox might be a good compromise for trying to combine the particles/physics UI into the modifier window, but I feel that should get discussion under a different topic as jonathan says. This topic is addressing a- reording the stack easily, b- communicating flow to new users (but without a fundamental change to physics etc.)

neutral/future comment:

  • if we're gonna do fundamental changes, I'd propose working on UI for nodal modifiers/constraints/particles etc. (Lukas is already exploring this) and how we're going to integrate it/handle it etc. would be kinda cool to have some UI issues figured out early for once :) and I like the "if you're going to be radical, be really radical, not just halfsies" mentality

No problem here, I agree that the debate has gone far enough - sounds reasonable to save the physics integration for later.

For fundamental changes I'd propose a node-based system too. That would allow for an intuitive, reusable/share-able, and powerful way of modifying meshes/objects. We could have a "Mesh" node that could be modified in a lot of ways, then linked to a particle system, and then modified again, for example; and so on. You guys know the possibilities, of course.

For the scope of this proposal, I would go with the following:

  • Drag & Drop;
  • Arrows to make the direction clear;
  • Clean up of the modifiers' UI's themselves in the way presented in my mockups or similar, to allow actual use of the modifier's name, allow for a grab area, and encapsulation of additional functionality to a menu(Additionally I would go with Ctrl LMB to rename too, so we'd be able to drag from that area, and also, it's consistent with other areas with renaming available on Blender[e.g. Outliner, Materials, Listboxs, etc]. In the end of the day, we don't need an Entry all the time, do we? We don't rename modifiers all the time, right?);
  • Color Value(Lightness) difference between the modifiers and the background; for clear separation between each other and the background itself;
  • Solo Mode(Ctrl LMB);
  • Easy way to deactivate/activate them all at once for both Viewport and Render;
  • And, as @bassam kurdali (bassamk) proposed, some way to add modifiers directly where you want them to be;

Obs.: Any comments on my mockups? Would be appreciated :)

Update from August 3rd UI Meeting

This was discussed during today's meeting. Agreement was reached that adding Drag and Drop re-ordering support for modifiers (and constraints) is first priority.

After drag and drop is added then we can re-open the discussion for additional changes.

@Warren Bahler (russcript) are you able/interested in working on this?

@ carter2422 - unfortunately , no, my knowledge with coding is limited to some basic scripting(no C experience ). So I'm not really qualified here.I'm hoping to keep learning though.

@Hyuri Pimentel (hyuristyle) i want to add:

  • A way to copy several modifiers from one object to another at once without overwriting existing modifiers on the target.

So you can reuse parts of modifier setups very quickly.

As far as i know "Make Links" (CTRL-L) is the only way at the moment, and there is no option to keep modifiers.

Edit: Thank you @Warren Bahler (russcript)

Another pro to the listbox that I haven't seen mentioned (but I may have missed it) is that the controls for adding new modifiers and deleting existing ones are always visisble, which isn't currently the case.
It also makes us inherit any development happening on the listbox, such as this improvement that was implemented: (example not from blender)

Other things I think could be beneficial to working with modifiers (disregarding the physics/particles for now, as requested by @Jonathan Williamson (carter2422)):
-A button that automatically creates an object (lattice/empty/curve) where ever such an object can be used to control something. Examples are the curve modifier, using an empty to set a mirror point, using a mesh or lattice to deform a mesh...
The displacement modifier already does this with images (it even features a button that takes you to the image tab to adjust its settings), and it'd be wonderful to extend that functionality to save the user time. You could automatically organise things as well, for instance scaling a lattice to the object's bounds, or naming it 'objectname_lattice', or parenting the newly created items to the object itself (for clarity in the outliner, but also so it moves with the object).
-Displaying multiple modifiers by shift/ctrl-clicking the listbox entries. Disregard the order of clicking and always display them in the order they're applied to the mesh, for clarity and consistency. This was mentioned before, so I'm just giving it my '+1' :)
-A toggle that switches between showing the full end result, or only all modifiers up untill the one(s) you have selected/displayed. This way, if you have for instance a few deforming modifiers below the current one (let's say deform, lattice and subdivision), you can easily toggle between previewing the final result and working on the mesh as it exists at the currently selected level, without having to turn on and off three modifiers every time. You could also hotkey this toggle.

I've really enjoyed seeing the rational discussion going on here, and I hope we can come to a truly great design. I work with modifiers daily (in modeling, hardly ever animation), and look forward to any improvements.

@ Karja, that's possible with the copy attributes addon, which I think should be enabled by default.but it's not really a good option for a button- perhaps a drop down menu for the modifier panel could contain options like this.

@ michaelknubben, the decision per the UI team seems to improve the current system slightly, in hopes that the nodal system can take over in the future.
I do like the automatic manipulator object creation idea, it would really simplify things for new users, but would be completely flexible as well.

I haven't seen anything to suggest that nodes will ever fully take over, where did you see this?
edit: In fact, Jonathan's comment indicates that they're considering these designs, but will first implement drag and drop for the short-term advantage.

Yeah :)
This is a way I would like to see modifier properties works. Thanks russcript for test add-on !!!

Drag&drop would be a great … and one small note: if a new modifier is added it would be more handy if it also become as selected item in the list, so we an directly continue setup properties. Like now its not and we have to manually select it from a list first.
Thank you.

Depending on the scope you are willing to go the solution could go from just a simple list as a UI component to implementing different selection contexts and dropping the buttons (properties) editor as a special case and just implementing panels collection as a editor type. This would bring consistency as panels are used everywhere as a properties editor anyway.

The selection context should be available to all data types and be constructed hierarchically. Of course pre-made panel sets should emulate the controls one has now. The same way the properties are accessible now from the datablocks. This would FINNALY enable changing data on many objects at once.

This is how property editor works in Softimage (I bet people get tired of SI references I make, I promise to stop soon :).

Its as flexible as it can get. For example you can select multiple render settings and get properties on all, with properties that are same values displayed normally and those that differ can be forced to same values or left alone. Same with any data that is exposed.

The arrows are used a lot in visual programming tools where you indicate how data is passed through nodes, so I think function wise they work well.

I also noticed that often students are not aware of that modifiers in Blender work top-down. The arrows could maybe help with that flow of data processing better.

Problem I see only is that nowhere else those arrows are being used.

The drag n drop is highly welcomed. I work in all my design files heavily with modifiers and I hate having to click the up down arrows a lot to move a modifier.

I would not follow Cole Reed idea of listing modifiers and having only one display area for the selected modifier. Often I need to see the data of many modifiers at once.

I would not follow Cole Reed idea of listing modifiers and having only one display area for the selected modifier. Often I need to see the data of many modifiers at once.

There is no need to have a hard limit for displaying only ONE selected modifier. As it was already mentioned before, it would be great to have ALL of selected modifiers in the list (for example with Shift+click) displayed in the area below the list.

Since the first 2.5x design, I believe that Properties editor should be splittable in 2 or 3 columns.
Tabs resolve problem in toolshelf but not for modifiers or particles tab.
In fact, panels were splitted in two columns. It makes a Properties editor taking the whole height of the window able to display 5 ,6 panels or 7, 8 (if you zoom out).
So, with a larger space taken by Properties editor splitted in 2 columns, double of modifiers could be seen in same time.

Sorry for uglu mock-up. I did it quickly.

I feel like this comment was glossed over, what are your thoughts on having the Properties window split into columns beyond a certain (window zoom-dependant) width?
It should be a value that's in- or decreased based on the window's current zoom, and exposed in the preferences so the user with uncommon needs can adjust it.
Similarly, I think this would be useful in the Outliner.

This would have the knock-on effect of making these window-types more useful when maximised as well.

Additionally it gives the UI team a default maximum width to design for, making it clear what length a label (for instance) could or should be to remain legible in ideal circumstances.

@michael knubben (michaelknubben), That design would be very clumsy in practice - there's a reason that no popular interface uses a "re-flow" of columns.
Just imagine scrolling with two columns - one would scroll down, while the other scrolled up to flow into it .This would be very confusing to use at best.You could limit scrolling to the last column, but then you have the weird situation of a non-linear representation, with modifiers in between the two ends of the stack being hidden.And then what happens when a modifier is too long to fit in one column.....?

I think its better to focus on a more layered ,self organizing approach to the problem.The solution can't simply be to display more and more info at once, that's one of the biggest issues with the overall interface already- and it can actually kill productivity instead of enhancing it.

Things like forcing panel collapse(only one panel open at once), the listbox approach, or using more popups and drop-down menus are examples of ways to fit more setting into a smaller,cleaner, and more manageable space.

on your last point, I do think setting some hard (or soft) limits to the layout dimensions could be beneficial,a lot of issues are caused by the unlimited flexibility. con is that we'd lose some flexibility, the pro's are as you mentioned, the layout could be optimized better - the headers running off the screen for example

I've used multiple columns like this for a long time. It's an improvement over this:
And it will only show up once the user has dragged his properties panel horizontally way past what's useful. It's a choice.

Just to clarify, this is offering a solution to pitfalls of the UI's flexibility, areas where the flexibility falls flat for certain window-types. Properties and Outliner mainly. You may argue it's not perfect, but it's a definite improvement over current behaviour, don't you think? I wouldn't want to limit the size of these windows at all, that'd go against the UI paradigm. Particularly for the Outliner, I sometimes absentmindedly maximise the Outliner thinking it'll give me more to work with, but it quickly loses purpose when fullscreen.

I'm personally not sold on collapsing panels at all. I use Zbrush a lot, It's a poor solution to a problem of organisation. I've moved all of my most-used commands into the main UI because those menus are so, so bad. You're constantly hunting for moving targets.

You're absolutely right that we need to focus on organising information smartly, the question just remains: how? I don't have a simple solution, and I don't have deep enough knowledge of every menu item that I could decide what should always be displayed and what should be put under a dropdown.

The listbox approach is the best solution offered by far, but the response hasn't been as positive as I'd hoped.
To my feeling it's already been dismissed with arguments like 'it doesn't show the direction of modifiers' (it can, show arrows) and 'it only shows one modifier at a time ' (No it doesn't, ctrl-click multiple modifiers).

not meaning to 'blur over' the idea but there are some practical issues with it that I don't really think could work.

multiple columns are fine if you wish, and you can easily split an editor already, but I still don't think the re-flow concept would work well at all.Imagine three columns of panels with the first few collapsed; now toggle them open and all three columns will completely reorganize, with some panels jumping from the bottom of the screen to the top as they flow through the columns.Then try about moving targets.You would also have dead space at the bottom of each column where the next panel couldn't fit.

I'm personally not sold on collapsing panels at all. I use Zbrush a lot, It's a poor solution to a problem of organisation. I've moved all of my >most-used commands into the main UI because those menus are so, so bad. You're constantly hunting for moving targets.

this example also points at a solution- you moved all your most used commands into the main interface because you could, and should, while the lesser used commands stay hidden until needed.A layered UI design would have to include this flexibility, eg. the pinning functionality of the toolbar tabs.This is getting kinda off topic though, it's more of a general UI design topic.

I'm aware of all the downsides, but I don't see a better solution to column's loss of function beyond certain sizes.
Even on top of the reorganisation and other proposals that are being proposed in here (and that's necessary, I'm not debating that!), I think this would be a good evolution of the UI. At best it's never seen by most users because through the reorganisation they rarely need or want to see more information than we can easily serve them with, but it's just a fact that one of the big selling points of Blender's UI system (flexibility and scalability) is being underutilised in a few window-types, and I don't see the downsides to offering this extra flexibility that's only seen when a window's become stretched far beyond what could be considered 'useful'.

And yes, I've used software that did this. It wasn't a 100% perfect situation, but the program struggled with similar problems (too much information to display in comfortable, at-a-glance ways), and two columns improved upon that significantly.

Our main focus should be on elegant solutions to the presentation of information, but I don't see any downsides to offering this as a refinement of the toolset, not a solution in itself.

[little OT: I have reordering working in the outliner, if that is of any interest... D1014: Outliner: allow drag n drop reordering the modifier stack]

To copy modifiers in outliner by drag&drop would be also great:)

BTW: russcript's listbox is such clear, clean and coherent with the rest of current UI, shame here is not someone able to implement.

Or does we wait for drag&drop reordering function here?

i also think that the listbox allows for much more consistency and functionality without cluttering the ui too much.

something to consider regarding this:

  • How about splitting the property editor in a top and bottom region, much like the toolshelf and last operator regions in the 3D view ?

The listbox with the stack can then be visible at all times, with only the lower region with the button panels scrolling, avoiding nested scrolling.

I think you can't see the solution for the modifier stack when just looking at this tab in isolation , the whole property editor type needs more coherence imho, particulary redesigning the top of each tab... which could then go into a subregion, like i propose for the modifier listbox.

there is the line with the pin and 'breadcrumb' . this could be made more usefull and consistent, or maybe it is partly redundant with the datablock line... it could for instance list the 'path', not the datablock name itself, since that is in the next line.

then there is the datablock line, with amount of users etc,... you always want to know what modifier / object / material / etc you work on right....
here alreay there is a lot of inconsistency both in order and alignment: the textarea coud expand to always fit this on one line, with the users buttons aligned right. on the material tab the datablock line sits under the materialslots listbox, the render, renderlayer and scene tabs don't have the scene datablock line. on the particles tab, there is a redundant 'type' label in fron of it... essentially, this jump too much all over the place... it would be nice if this would be one consistent line across all tabs.

most things return for each type of data, so some more consistency and alignment for the breadcrumb, would clear up the property editor. when having multiple scenes for instance, the datablock name should swith to a selectable one with a popup list, like the other tabs.

This top 'info' panel/region could be seen like a simplified mini outliner, consistent and focused to the data type of the tab, then with the outliner getting some more love there would be a natural learning curve to more outliner use. Also, in the materialstab, the preview panel could be pinned here as well.

Thinking further, with a good design of the top region, essentially telling what data the scrolling area's region with the buttons themselves underneath acts on - be it a modifier in a stack or anything else - would allow for a default layout without outliner above the properties editor, giving more space to proposed upper and lower region.

not sure if i can bring my points across with words here...

one last thing: Since blender is so cutomisable in regard to screen area's, why try to cram all this functionality of seeing several modifiers / objects at once when you could just add another property editor. This just needs to be made more clear to new users. A better more consistent design of the top part of the button tabs and better pinning would make this even more clear / useful / powerfull.

Side note: I made the basic implementation for Modifier Drag & Drop which can currently be tested in the gooseberry branch. As I said, it is pretty basic, without any animations or such, but it's a start ;)