Modifiers UI #38178

New Issue

Closed

opened 2014-01-13 00:01:02 +01:00 by William Reynish · 125 comments

William Reynish commented 2014-01-13 00:01:02 +01:00

Member

Copy Link

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)

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) 

William Reynish commented 2014-01-13 00:01:02 +01:00

Author

Member

Copy Link

Changed status to: 'Open'

Changed status to: 'Open'

William Reynish commented 2014-01-13 00:01:02 +01:00

Author

Member

Copy Link

Added subscriber: @billrey

Added subscriber: @billrey

lopata commented 2014-01-13 00:37:51 +01:00

Copy Link

Added subscriber: @lopataasdf

Added subscriber: @lopataasdf

lopata commented 2014-01-13 00:37:51 +01:00

Copy Link


Thomas Dinges commented 2014-01-13 01:53:37 +01:00

Owner

Copy Link

Added subscriber: @ThomasDinges

Added subscriber: @ThomasDinges

xrg commented 2014-01-13 04:18:33 +01:00

Copy Link

Added subscriber: @xrg

Added subscriber: @xrg

xrg commented 2014-01-13 04:21:26 +01:00

Copy Link

There is also this older proposal (PDF) that I always thought was pretty solid.

There is also [this older proposal (PDF) ](http://tenderlovingdesign.com/storage/blender/Modifier_Proposal.pdf) that I always thought was pretty solid.

michael knubben commented 2014-01-13 10:27:10 +01:00

Copy Link

Added subscriber: @michaelknubben

Added subscriber: @michaelknubben

michael knubben commented 2014-01-13 10:27:10 +01:00

Copy Link

I made a proposal a while back, but I must say I'm fond of some of the more extreme proposals in here. Nevertheless, I thought I'd add this to the conversation:

The idea of placing the name onto a line with very little else in it could be combined with other proposals. I think it's an important goal to be able to read the modifier's name when the Properties Panel is at the width as seen in Blender's current default screen layout.

I still think presets are very important, even more so if they'd have the power to add things to the scene (think: adding an empty or curve for the array modifier)

Here's some other stuff I've written down on the matter at one point:

• Wherever an object can be used to control a modifier, add a button that can automatically create one. For example, in a Mirror modifier, in the 'Mirror Object' dropdown, add a button which creates an empty at the current mirror-point. Then have it automatically selected so the user can tweak it.
• Drag & Drop modifiers allows one to get rid of the arrows, clearing up more much needed space.
• The default interface doesn’t allow a Modifier’s name to be read past the first few letters on common screen resolutions.
• The arrows don't currently work well, in my opinion. The instant jumping up and down of the modifiers makes things hard to follow.

I made a proposal a while back, but I must say I'm fond of some of the more extreme proposals in here. Nevertheless, I thought I'd add this to the conversation:  The idea of placing the name onto a line with very little else in it could be combined with other proposals. I think it's an important goal to be able to read the modifier's name when the Properties Panel is at the width as seen in Blender's current default screen layout. I still think presets are very important, even more so if they'd have the power to add things to the scene (think: adding an empty or curve for the array modifier) Here's some other stuff I've written down on the matter at one point: - Wherever an object can be used to control a modifier, add a button that can automatically create one. For example, in a Mirror modifier, in the 'Mirror Object' dropdown, add a button which creates an empty at the current mirror-point. Then have it automatically selected so the user can tweak it. - Drag & Drop modifiers allows one to get rid of the arrows, clearing up more much needed space. - The default interface doesn’t allow a Modifier’s name to be read past the first few letters on common screen resolutions. - The arrows don't currently work well, in my opinion. The instant jumping up and down of the modifiers makes things hard to follow.

William Reynish commented 2014-01-13 12:53:56 +01:00

Author

Member

Copy Link

@michaelknubben: Yes, those are similar ideas.

Re: putting the title and the X in a different line, we could do this, but it would mean that modifiers would take up extra space. The advantage would be that there would be extra header space to drag the modifiers, and that there'd be enough space to display everything, without having to make the properties too wide..

@michaelknubben: Yes, those are similar ideas. Re: putting the title and the X in a different line, we could do this, but it would mean that modifiers would take up extra space. The advantage would be that there would be extra header space to drag the modifiers, and that there'd be enough space to display everything, without having to make the properties too wide..

michael knubben commented 2014-01-13 13:08:01 +01:00

Copy Link

It's a shame, but I believe we must admit the current panel-height is achieved at the expense of legibility. Perhaps we can place the Apply and Copy elsewhere too, or (and I like this, myself) make them smaller icons. 'Apply' could be an arrow going onto a mesh, and 'Copy' could use the existing one of an arrow onto a clipboard.

It's a shame, but I believe we must admit the current panel-height is achieved at the expense of legibility. Perhaps we can place the Apply and Copy elsewhere too, or (and I like this, myself) make them smaller icons. 'Apply' could be an arrow going onto a mesh, and 'Copy' could use the existing one of an arrow onto a clipboard.

William Reynish commented 2014-01-13 14:33:24 +01:00

Author

Member

Copy Link

Yes, the Apply, Apply as Shape and Copy buttons could go on the same line as the enable/disable toggles, so that we don't add an extra row.

Yes, the Apply, Apply as Shape and Copy buttons could go on the same line as the enable/disable toggles, so that we don't add an extra row.

Warren Bahler commented 2014-01-13 17:04:57 +01:00

Copy Link

Added subscriber: @WarrenBahler

Added subscriber: @WarrenBahler

Warren Bahler commented 2014-01-13 17:04:57 +01:00

Copy Link

thumbs up to the ideas here,

What do you think of this proposal by Cole Reed. I think its a great idea to combine the physics, particles and modifiers panel for a unified "pipeline", as is proposed in depth here:

http://tenderlovingdesign.com/storage/blender/Modifier_Proposal.pdf

this design also eliminates most of the long scrolling problems for the panels involved, and helps distinguish which modifier, or physics system your activity editing. Currently, if you have more than one physics type on an object, the panels in the physics tab run together with no visible division, making it very confusing at times.

thumbs up to the ideas here, What do you think of this proposal by Cole Reed. I think its a great idea to combine the physics, particles and modifiers panel for a unified "pipeline", as is proposed in depth here: http://tenderlovingdesign.com/storage/blender/Modifier_Proposal.pdf this design also eliminates most of the long scrolling problems for the panels involved, and helps distinguish which modifier, or physics system your activity editing. Currently, if you have more than one physics type on an object, the panels in the physics tab run together with no visible division, making it very confusing at times. 

Matjaž Lamut commented 2014-01-13 17:53:05 +01:00

Copy Link

Added subscriber: @lamoot

Added subscriber: @lamoot

Matjaž Lamut commented 2014-01-13 17:53:05 +01:00

Copy Link

The original proposal is good and it'll definitely be an improvement if implemented but I feel it only solves a small part of the problem with the modifiers UI.

@xrg and @WarrenBahler already linked to the proposal by Cole Reed, so rather than another link, a +1 to that proposal. It's very much worth the read.

The original proposal is good and it'll definitely be an improvement if implemented but I feel it only solves a small part of the problem with the modifiers UI. @xrg and @WarrenBahler already linked to the proposal by Cole Reed, so rather than another link, a +1 to that proposal. It's very much worth the read.

michael knubben commented 2014-01-13 20:54:51 +01:00

Copy Link

I agree, that proposal is an improvement. Certainly because since he wrote it, list views themselves were improved which would now benefit this design.

It combines quite well with some of the suggestions in this thread, too. And it solves the Proporties 'faux-tabs' being so wide, although now that tabs are a UI element in Blender I imagine we'll use them in the Properties Panel as well.

I agree, that proposal is an improvement. Certainly because since he wrote it, list views themselves were improved which would now benefit this design. It combines quite well with some of the suggestions in this thread, too. And it solves the Proporties 'faux-tabs' being so wide, although now that tabs are a UI element in Blender I imagine we'll use them in the Properties Panel as well.

Adam Friesen commented 2014-01-13 21:14:00 +01:00

Copy Link

Added subscriber: @Ace_Dragon

Added subscriber: @Ace_Dragon

Adam Friesen commented 2014-01-13 21:14:00 +01:00

Copy Link

Hi, I have a suggestion which is in part, a UI element and part, functionality in general.

Would it be too much of a stretch to add an option to allow the user to disable live updates in favor of a 'calculate stack' button. I ask this because complex modifier operations on large meshes (like decimation) can take a minute or more to complete and it can be annoying to have to constantly wait just because one makes a small tweak to a value (that and the fact that it makes dragging value sliders impossible).

The proposal in general looks good though (like a lot of others you made that utilizes the existing UI concepts).

Hi, I have a suggestion which is in part, a UI element and part, functionality in general. Would it be too much of a stretch to add an option to allow the user to disable live updates in favor of a 'calculate stack' button. I ask this because complex modifier operations on large meshes (like decimation) can take a minute or more to complete and it can be annoying to have to constantly wait just because one makes a small tweak to a value (that and the fact that it makes dragging value sliders impossible). The proposal in general looks good though (like a lot of others you made that utilizes the existing UI concepts).

michael knubben commented 2014-01-13 21:15:29 +01:00

Copy Link

That is actually a very good suggestion (and I feel silly for not having brought it up myself, as I've struggle with the same issue!), but probably a seperate issue. But it's good to brainstorm button look/placement here!

That is actually a very good suggestion (and I feel silly for not having brought it up myself, as I've struggle with the same issue!), but probably a seperate issue. But it's good to brainstorm button look/placement here!

William Reynish commented 2014-01-13 23:34:29 +01:00

Author

Member

Copy Link

@Ace_Dragon: That's a fairly important issue, but it's not really directly related to modifiers specifically. The way live updating works could be handled in a number of different ways. Probably the nicest way from a user perspective would be to have the view and UI elements be multithreaded, so that a slow updating viewport would not slow down the UI interaction. You always what the UI element to react instantly, even if it takes a while to update or display the result in the 3D View.

@WarrenBahler: I remember seeing a suggestion like this before. Depending on the size of the modifiers, this could make sense. The same thing has been suggested for the nodes UI too, to place the settings for the current node separately from the node itself. It has advantages and disadvantages.

The advantage is that it's more space efficient, and as such it'd better for large, complex modifiers. It could allow for consolidating things into the modifier stack, such as the physics and particles settings that currently open in separate properties tabs.

The disadvantage is that it requires and extra click to view settings for the modifier, and that the relationship between active modifier and its settings is not as direct. Also, by default you'd only see the settings of one modifier at a time.

@michaelknubben:
As we discussed, here's a version with a clearer header for dragging:

@Ace_Dragon: That's a fairly important issue, but it's not really directly related to modifiers specifically. The way live updating works could be handled in a number of different ways. Probably the nicest way from a user perspective would be to have the view and UI elements be multithreaded, so that a slow updating viewport would not slow down the UI interaction. You always what the UI element to react instantly, even if it takes a while to update or display the result in the 3D View. @WarrenBahler: I remember seeing a suggestion like this before. Depending on the size of the modifiers, this could make sense. The same thing has been suggested for the nodes UI too, to place the settings for the current node separately from the node itself. It has advantages and disadvantages. The advantage is that it's more space efficient, and as such it'd better for large, complex modifiers. It could allow for consolidating things into the modifier stack, such as the physics and particles settings that currently open in separate properties tabs. The disadvantage is that it requires and extra click to view settings for the modifier, and that the relationship between active modifier and its settings is not as direct. Also, by default you'd only see the settings of one modifier at a time. @michaelknubben: As we discussed, here's a version with a clearer header for dragging: 

Warren Bahler commented 2014-01-14 00:51:05 +01:00

Copy Link

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

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

Karja Krähwald commented 2014-01-14 04:31:47 +01:00

Copy Link

Added subscriber: @karja

Added subscriber: @karja

Karja Krähwald commented 2014-01-14 04:31:47 +01:00

Copy Link

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)

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)

Jonathan Williamson commented 2014-01-14 19:23:07 +01:00

Member

Copy Link

Added subscriber: @JonathanWilliamson

Added subscriber: @JonathanWilliamson

Matjaž Lamut commented 2014-01-15 21:34:13 +01:00

Copy Link

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.

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.

Jonathan Williamson commented 2014-01-27 19:54:17 +01:00

Member

Copy Link

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

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

Warren Bahler commented 2014-01-27 21:56:50 +01:00

Copy Link

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.

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.

Paweł Łyczkowski commented 2014-01-28 12:45:12 +01:00

Copy Link

Added subscriber: @PawelLyczkowski-1

Added subscriber: @PawelLyczkowski-1

Forest Ka commented 2014-01-29 06:38:45 +01:00

Copy Link

Added subscriber: @forest-ka

Added subscriber: @forest-ka

Forest Ka commented 2014-01-29 06:38:45 +01:00

Copy Link

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

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

Diego Gangl commented 2014-01-29 23:07:42 +01:00

Copy Link

Added subscriber: @Januz

Added subscriber: @Januz

bassam kurdali commented 2014-02-02 23:30:02 +01:00

Member

Copy Link

Added subscriber: @BassamKurdali

Added subscriber: @BassamKurdali

bassam kurdali commented 2014-02-02 23:35:39 +01:00

Member

Copy Link

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!

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!

Andrew Price commented 2014-02-10 07:31:57 +01:00

Copy Link

Added subscriber: @AndrewPrice

Added subscriber: @AndrewPrice

Andrew Price commented 2014-02-10 07:31:57 +01:00

Copy Link

Love the idea @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?

Love the idea @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 ](http://ux.stackexchange.com/questions/25030/is-apples-or-googles-meaning-of-the-three-horizontal-bar-icon-more-popular/25032#25032)).  **Version 2** - 3 bars for reordering - [Used in most iOS apps ](http://ux.stackexchange.com/questions/26121/what-is-a-good-visual-cue-for-drag-and-drop-for-reordering-a-list-of-items)  **Version 3** - Ribs. Standard in many software like Photoshop.  Which do you think best symbolizes reordering?

bassam kurdali commented 2014-02-11 21:51:40 +01:00

Member

Copy Link

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.

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.

Karja Krähwald commented 2014-02-12 22:43:50 +01:00

Copy Link

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.

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.

bassam kurdali commented 2014-02-12 22:55:19 +01:00

Member

Copy Link

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.

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.

Warren Bahler commented 2014-02-12 23:15:55 +01:00

Copy Link

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)

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)

Diego Gangl commented 2014-02-12 23:32:33 +01:00

Copy Link

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.

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.

Andrew Price commented 2014-02-13 03:23:04 +01:00

Copy Link

@WarrenBahler
Actually that may be an argument against using that symbol, since they perform completely different functions and would therefore confuse users.

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

@WarrenBahler Actually that may be an argument against using that symbol, since they perform completely different functions and would therefore confuse users. @BassamKurdali & @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 ](http://imgur.com/hbBvBtf,L0CvHcO#1), indicator that an action can be performed. - When clicked and dragged, the icon changes to a [grab icon ](http://imgur.com/hbBvBtf,L0CvHcO#0), which tears the modifier header to the mouses movements, indicating that the modifier can be moved.

Nick Hennig commented 2014-02-13 16:23:29 +01:00

Copy Link

Added subscriber: @nickhennig56

Added subscriber: @nickhennig56

Diego Gangl commented 2014-02-13 18:11:16 +01:00

Copy Link

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

@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 ](http://www.jaycodesign.co.nz/css/cross-browser-css-grab-cursors-for-dragging/) would be better, and then the grabbing hand when dragging.

Felix Beaulieu commented 2014-02-14 01:28:31 +01:00

Copy Link

Added subscriber: @FelixBeaulieu

Added subscriber: @FelixBeaulieu

Bartosz Moniewski commented 2014-03-26 10:18:01 +01:00

Copy Link

Added subscriber: @BartekMoniewski

Added subscriber: @BartekMoniewski

Tillmann Schütz commented 2014-04-03 16:44:24 +02:00

Copy Link

Added subscriber: @ionarn

Added subscriber: @ionarn

Karja Krähwald commented 2014-04-14 19:52:22 +02:00

Copy Link

Hey!

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.

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

Warren Bahler commented 2014-04-14 21:19:44 +02:00

Copy Link

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.

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.

Bastien Montagne commented 2014-05-20 16:13:46 +02:00

Owner

Copy Link

Added subscriber: @mont29

Added subscriber: @mont29

Vlad Mafteiu Scai commented 2014-07-03 09:07:49 +02:00

Copy Link

Added subscriber: @00Ghz

Added subscriber: @00Ghz

Vlad Mafteiu Scai commented 2014-07-03 09:07:49 +02:00

Copy Link

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

Here is my rough proposal.

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

Warren Bahler commented 2014-07-23 03:33:43 +02:00

Copy Link

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)
https://www.dropbox.com/s/dubdq65aiycup1t/properties_data_modifier.py

2.(re) start blender

3. install the addon and test :)
   https://www.dropbox.com/s/p97hwlmiotm40ga/Modifier_ListBox_Addon.py

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) https://www.dropbox.com/s/dubdq65aiycup1t/properties_data_modifier.py 2.(re) start blender 3. install the addon and test :) https://www.dropbox.com/s/p97hwlmiotm40ga/Modifier_ListBox_Addon.py 

Jonathan Williamson commented 2014-07-23 04:16:34 +02:00

Member

Copy Link

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

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

ronan ducluzeau commented 2014-07-23 09:51:02 +02:00

Copy Link

Added subscriber: @zeauro

Added subscriber: @zeauro

ronan ducluzeau commented 2014-07-23 09:51:02 +02:00

Copy Link

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

xrg commented 2014-07-23 19:02:41 +02:00

Copy Link

I like the listbox approach in @WarrenBahler'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.

I like the listbox approach in @WarrenBahler'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.

Jonathan Williamson commented 2014-07-23 20:18:46 +02:00

Member

Copy Link

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

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

bassam kurdali commented 2014-07-23 22:42:25 +02:00

Member

Copy Link

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

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

Paweł Łyczkowski commented 2014-07-24 00:16:14 +02:00

Copy Link

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

> @JonathanWilliamson - 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 commented 2014-07-24 00:27:42 +02:00

Copy Link

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:
https://www.youtube.com/watch?v=yhMl_EJib2c

I think full nodification is still far away though.

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: https://www.youtube.com/watch?v=yhMl_EJib2c I think full nodification is still far away though.

Warren Bahler commented 2014-07-24 00:56:15 +02:00

Copy Link

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

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

@JonathanWilliamson -Thanks for the feedback, I agree with the concern about the "top down" being clear but as @xrg mentioned, many applications use a layer system that processes top down, so the concept is quite familiar to most users.it's also an option to add a UI element (such as an arrow) that indicates the sequence order. @BassamKurdali - 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 @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.

bassam kurdali commented 2014-07-24 02:44:00 +02:00

Member

Copy Link

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)

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)

Yousef Harfoush commented 2014-07-24 05:00:39 +02:00

Member

Copy Link

Added subscriber: @bat3a

Added subscriber: @bat3a

Yousef Harfoush commented 2014-07-24 05:00:39 +02:00

Member

Copy Link

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!

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! example: 

Warren Bahler commented 2014-07-24 13:47:49 +02:00

Copy Link

@BassamKurdali, 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

@BassamKurdali, 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

Vlad Mafteiu Scai commented 2014-07-24 13:57:30 +02:00

Copy Link

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.

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.

ronan ducluzeau commented 2014-07-24 16:15:55 +02:00

Copy Link

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.

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.

Diego Gangl commented 2014-07-25 02:17:47 +02:00

Copy Link

@PawelLyczkowski-1 Reversing the stacks is an interesting idea. My only worries would be old tutorials and performance when flipping a +70 stack.

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

HAIR_nose
HAIR_armpit
HAIR_ear

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.

@PawelLyczkowski-1 Reversing the stacks is an interesting idea. My only worries would be old tutorials and performance when flipping a +70 stack. @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: HAIR_nose HAIR_armpit HAIR_ear 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.

Warren Bahler commented 2014-07-25 03:05:34 +02:00

Copy Link

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.

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

ronan ducluzeau commented 2014-07-25 10:32:26 +02:00

Copy Link

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.

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.

bassam kurdali commented 2014-07-28 19:44:00 +02:00

Member

Copy Link

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

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

Blake Stacks commented 2014-07-28 20:02:36 +02:00

Copy Link

Added subscriber: @blakenator

Added subscriber: @blakenator

Blake Stacks commented 2014-07-28 20:02:36 +02:00

Copy Link

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?

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?

xrg commented 2014-07-29 00:49:02 +02:00

Copy Link

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

https://www.youtube.com/watch?v=ixoByEJFKQw&feature=youtu.be

Rather than typing, I just made a video overview of why I think the listbox approach is better: https://www.youtube.com/watch?v=ixoByEJFKQw&feature=youtu.be

Hyuri Pimentel commented 2014-07-29 04:09:47 +02:00

Copy Link

Added subscriber: @Hyuri

Added subscriber: @Hyuri

Hyuri Pimentel commented 2014-07-29 04:09:47 +02:00

Copy Link

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 @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:
http://pics.computerbase.de/5/6/3/6/3/3_m.png
http://www.omgubuntu.co.uk/wp-content/uploads/2014/01/popover-normal.png

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!

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 @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: http://pics.computerbase.de/5/6/3/6/3/3_m.png http://www.omgubuntu.co.uk/wp-content/uploads/2014/01/popover-normal.png 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!

Blake Stacks commented 2014-07-29 19:59:56 +02:00

Copy Link

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?

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?

Blake Stacks commented 2014-07-29 20:21:54 +02:00

Copy Link

Something like this: Modifier_ListBox_Addon.py

Something like this: [Modifier_ListBox_Addon.py](https://archive.blender.org/developer/F100192/Modifier_ListBox_Addon.py)

Vlad Mafteiu Scai commented 2014-07-29 20:28:51 +02:00

Copy Link

Removed subscriber: @00Ghz

Removed subscriber: @00Ghz

bassam kurdali commented 2014-07-30 01:58:11 +02:00

Member

Copy Link

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.

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.

Warren Bahler commented 2014-07-30 03:00:19 +02:00

Copy Link

@BassamKurdali

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.

http://tenderlovingdesign.com/storage/blender/Modifier_Proposal.pdf

you could also watch the video above posted by @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.

@BassamKurdali >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. http://tenderlovingdesign.com/storage/blender/Modifier_Proposal.pdf you could also watch the video above posted by @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.

ronan ducluzeau commented 2014-07-30 21:43:07 +02:00

Copy Link

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

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

bassam kurdali commented 2014-07-31 00:16:15 +02:00

Member

Copy Link

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.

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

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

Jonathan Williamson commented 2014-07-31 04:08:54 +02:00

Member

Copy Link

In #38178#79, @xrg wrote:
Rather than typing, I just made a video overview of why I think the listbox approach is better:

https://www.youtube.com/watch?v=ixoByEJFKQw&feature=youtu.be

Thanks for doing this video @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.

> In #38178#79, @xrg wrote: > Rather than typing, I just made a video overview of why I think the listbox approach is better: > > https://www.youtube.com/watch?v=ixoByEJFKQw&feature=youtu.be Thanks for doing this video @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.

bassam kurdali commented 2014-07-31 23:06:55 +02:00

Member

Copy Link

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

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

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

Proposal
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

Here's my comment, building off the original proposal and some of the comments so far: - Single biggest improvement (and imo, single biggest problem with current modifier stack) is the drag and drop reordering. This will save so much bother. - I'd like to see a way to insert a modifier in a single step right where it should be: **Problem** 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. **Proposal** 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

bassam kurdali commented 2014-07-31 23:20:58 +02:00

Member

Copy Link

@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

@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

Warren Bahler commented 2014-08-01 03:24:32 +02:00

Copy Link

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

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

Hyuri Pimentel commented 2014-08-01 04:01:20 +02:00

Copy Link

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 @BassamKurdali proposed, some way to add modifiers directly where you want them to be;

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

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 @BassamKurdali proposed, some way to add modifiers directly where you want them to be; Obs.: Any comments on my mockups? Would be appreciated :)

Jonathan Williamson commented 2014-08-03 18:34:33 +02:00

Member

Copy Link

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.

@WarrenBahler are you able/interested in working on this?

### 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. @WarrenBahler are you able/interested in working on this?

Sean Olson commented 2014-08-03 19:21:55 +02:00

Member

Copy Link

Added subscriber: @liquidape

Added subscriber: @liquidape

Warren Bahler commented 2014-08-04 13:27:01 +02:00

Copy Link

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

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

Sergei Smyslov commented 2014-08-08 04:15:09 +02:00

Copy Link

Added subscriber: @Luarvik

Added subscriber: @Luarvik

Karja Krähwald commented 2014-08-10 02:45:20 +02:00

Copy Link

@Hyuri 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 @WarrenBahler

@Hyuri 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 @WarrenBahler

michael knubben commented 2014-08-10 13:43:07 +02:00

Copy Link

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: https://dl.dropboxusercontent.com/u/17715/BL_outliner_eyes.gif (example not from blender)

Other things I think could be beneficial to working with modifiers (disregarding the physics/particles for now, as requested by @JonathanWilliamson):

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

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: https://dl.dropboxusercontent.com/u/17715/BL_outliner_eyes.gif (example not from blender) Other things I think could be beneficial to working with modifiers (disregarding the physics/particles for now, as requested by @JonathanWilliamson): - 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.

Warren Bahler commented 2014-08-10 14:41:29 +02:00

Copy Link

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

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

michael knubben commented 2014-08-10 16:23:36 +02:00

Copy Link

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.

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.

filip mond commented 2014-08-17 18:43:02 +02:00

Copy Link

Added subscriber: @FilipMond

Added subscriber: @FilipMond

filip mond commented 2014-08-17 18:43:02 +02:00

Copy Link

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.

Yeah :) This is a way I would like to see [modifier properties ](https://developer.blender.org/file/data/qsiaiantcr24t45bpblu/PHID-FILE-ltbekulxpeaj7a5ebvog/Capture.PNG) 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.

Igor Donevski commented 2014-08-18 17:41:46 +02:00

Copy Link

Added subscriber: @el_diablo

Added subscriber: @el_diablo

Igor Donevski commented 2014-08-18 17:41:46 +02:00

Copy Link

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.

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.

claas eicke commented 2014-08-31 23:39:15 +02:00

Copy Link

Added subscriber: @ClaasKuhnen

Added subscriber: @ClaasKuhnen

claas eicke commented 2014-08-31 23:39:15 +02:00

Copy Link

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.

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.

Sergei Smyslov commented 2014-09-01 03:53:42 +02:00

Copy Link

In #38178#106, @ClaasKuhnen wrote:
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.

> In #38178#106, @ClaasKuhnen wrote: > 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.

xrg commented 2014-09-01 11:21:39 +02:00

Copy Link

Removed subscriber: @xrg

Removed subscriber: @xrg

michael knubben commented 2014-11-11 12:06:58 +01:00

Copy Link

In #38178#245277, @zeauro wrote:
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.

> In #38178#245277, @zeauro wrote: > 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.

Warren Bahler commented 2014-11-11 17:15:10 +01:00

Copy Link

@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

@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

Julian Eisel self-assigned this 2014-11-11 17:23:37 +01:00

michael knubben commented 2014-11-12 09:17:34 +01:00

Copy Link

I've used multiple columns like this for a long time. It's an improvement over this:
https://dl.dropboxusercontent.com/u/17715/Schermafdruk%202014-11-12%2008.55.44.png
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).

I've used multiple columns like this for a long time. It's an improvement over this: https://dl.dropboxusercontent.com/u/17715/Schermafdruk%202014-11-12%2008.55.44.png 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).

Warren Bahler commented 2014-11-13 04:33:33 +01:00

Copy Link

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

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

michael knubben commented 2014-11-22 12:07:48 +01:00

Copy Link

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.

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.

Philipp Oeser commented 2015-01-30 12:27:27 +01:00

Member

Copy Link

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk

Philipp Oeser commented 2015-01-30 12:27:27 +01:00

Member

Copy Link

[little OT: I have reordering working in the outliner, if that is of any interest... {D1014}]

[little OT: I have reordering working in the outliner, if that is of any interest... {[D1014](https://archive.blender.org/developer/D1014)}]

filip mond commented 2015-01-30 23:21:11 +01:00

Copy Link

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?

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?

Frederick Desimpel commented 2015-02-07 13:41:15 +01:00

Copy Link

Added subscriber: @FDesimpel

Added subscriber: @FDesimpel

Frederick Desimpel commented 2015-02-07 13:41:15 +01:00

Copy Link

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.

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.

Julian Eisel commented 2015-03-08 23:20:02 +01:00

Member

Copy Link

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

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

Lapineige commented 2019-02-13 10:06:39 +01:00

Copy Link

Added subscriber: @Lapineige

Added subscriber: @Lapineige

Lapineige commented 2019-02-13 10:06:40 +01:00

Copy Link

Removed subscriber: @Lapineige

Removed subscriber: @Lapineige

Lapineige commented 2019-02-13 10:06:43 +01:00

Copy Link

Added subscriber: @Lapineige

Added subscriber: @Lapineige

xan2622 commented 2019-06-28 06:53:52 +02:00

Copy Link

Added subscriber: @xan2622

Added subscriber: @xan2622

xan2622 commented 2019-06-28 06:53:52 +02:00

Copy Link

You can follow this RightClickSelect topic to know what some blender users have been brainstorming about the modifiers stack (addons provided):
https:*blender.community/c/rightclickselect/ksdbbc/

You can follow this RightClickSelect topic to know what some blender users have been brainstorming about the modifiers stack (addons provided): [https:*blender.community/c/rightclickselect/ksdbbc/ ](https:*blender.community/c/rightclickselect/ksdbbc/)

Julian Eisel removed their assignment 2020-04-19 15:48:12 +02:00

William Reynish was assigned by Julian Eisel 2020-04-19 15:48:12 +02:00

Julian Eisel commented 2020-04-19 15:48:12 +02:00

Member

Copy Link

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly

Julian Eisel commented 2020-04-19 15:48:12 +02:00

Member

Copy Link

Assigning to William since this is a design task. However @HooglyBoogly is currently working on this.

Assigning to William since this is a design task. However @HooglyBoogly is currently working on this.

Hyuri Pimentel commented 2020-04-19 16:31:27 +02:00

Copy Link

Removed subscriber: @Hyuri

Removed subscriber: @Hyuri

Hans Goudey commented 2020-06-24 18:27:09 +02:00

Member

Copy Link

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'

Hans Goudey closed this issue 2020-06-24 18:27:09 +02:00

Pablo Vazquez referenced this issue 2023-08-25 21:12:23 +02:00

Modifiers UI Overhaul #111538

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

brush-assets-project

blender-v3.3-release

blender-v3.6-release

partial-write-refactor

universal-scene-description

blender-v4.1-release

blender-v3.6-temp_wmoss_animrig_public

temp-sculpt-dyntopo

gpencil-next

anim/animation-id-113594

blender-v4.0-release

blender-projects-basics

bridge-curves

sculpt-blender

asset-browser-frontend-split

asset-shelf

tmp-usd-python-mtl

tmp-usd-3.6

blender-v3.5-release

blender-v2.93-release

realtime-clock

sculpt-dev

bevelv2

xr-dev

v4.1.1

v3.6.11

v3.3.18

v4.1.0

v3.3.17

v3.6.10

v3.6.9

v3.3.16

v3.6.8

v3.6.7

v3.3.14

v4.0.2

v4.0.1

v4.0.0

v3.6.5

v3.3.12

v3.6.4

v3.6.3

v3.3.11

v3.6.2

v3.3.10

v3.6.1

v3.3.9

v3.6.0

v3.3.8

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

Labels

Clear labels   

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

This issue affects/is about backward or forward 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

Issues relating to Wayland windowing support.

  

Interest

Workbench

  

Interest: X11

Issues relating to Xorg/X11 support.

  

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

Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  

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

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

William Reynish

36 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#38178

No description provided.