Page MenuHome

Multi-Object Properties Editing
Confirmed, NormalPublicDESIGN

Authored By
William Reynish (billreynish)
Apr 27 2018, 1:41 PM
Tokens
"Love" token, awarded by xdanic."Love" token, awarded by Oskar."Burninate" token, awarded by Dir-Surya."100" token, awarded by Peps."Love" token, awarded by LeoSch."Love" token, awarded by Schiette."Love" token, awarded by hitrpr."Burninate" token, awarded by tilapiatsu."Love" token, awarded by Draise."Pterodactyl" token, awarded by shader."Love" token, awarded by Shimoon."Love" token, awarded by pierogo."Love" token, awarded by nunoconceicao."Love" token, awarded by jc4d."Burninate" token, awarded by eobet."Love" token, awarded by franMarz."Love" token, awarded by Dabi."Love" token, awarded by amonpaike."Love" token, awarded by looch."Love" token, awarded by Scaredyfish."Burninate" token, awarded by MetinSeven."Love" token, awarded by A.Lex_3D."100" token, awarded by Tetone."Love" token, awarded by Zuorion."Love" token, awarded by Arkhangels."Love" token, awarded by duarteframos."Love" token, awarded by lcs_cavalheiro."Love" token, awarded by SteffenD."Love" token, awarded by sebastianmroy.

Description

In Blender, we want to make it easier to set values for multiple objects, bones, strips, keys and other items at once.

Currently you can do this in limited circumstances, but you have to right-click on a value after you've changed it and pick Copy to Selected from the menu or hold Alt while editing values. This not only slow, but also very hidden, and the Alt-key conflicts with Emulate 3 Button Mouse. Lastly, it isn't clear at all to users which values work for multi-editing, and which values don't.

Here's how we would like to solve it:

Selection vs Active

The concept of active in Blender means that we only show properties and only affect the active object or item. However, if we want to better support multi-item editing, we must start by making it so the Properties reflects the selection rather than the active item, of which there can only be one. Going forward, by default the Properties will be set to reflect the selection instead. This could be controlled in the Properties like so:


(The search box is added here to reflect how the Properties will be updated when that item is also added, but is a separate feature)

If set to Active, the Properties will continue to function as it does today, only showing properties for the active item.

When there are multiple selected items

When the user has selected multiple items, a few things change:

Instead of showing the name of the object at the top, Blender tells the user how many items are selected:

In the list of tabs, only properties sections are shown that are common among the selected items. For example, if you select a text and a mesh object, we don't show Modifier, Mesh or Curve Properties, since these properties only exist on a subset of the selected objects:

This rule also goes for individual panels. Here, both a Sun and Spot light are selected, and we only see properties that are shared between them. A note at the bottom clarifies that you are only seeing the shared subset:

When values differ

When multiple items are selected, Blender will compare values to check if they are the same, or if they are different. If they differ, we change the way properties are displayed, like so:

Manipulating values across multiple items

For simply setting a value to be the same. you would simply type a new value, hit Return, and that value is then propagated to the selection.

For manipulating numbers and sliders relatively, you can just drag on them (like Alt-dragging today), or type the character '=', so the user can type '= -3' to subtract 3 from the value on all selected items.

Event Timeline

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

This task is marked "Closed, Resolved" but the functionality is not yet inside 2.80. So is this still on the agenda?

Resolved here means the design is approved. There is a separate task about implementing this: T54987: Implement Multi-Object Properties Editing.

What about how object properties values are displaye·d?

I think if default behavior will be editing multiple values, so as displayed values should also be somewhat consistent with that. With "?"/"-" mark or averaged value.

Eg like that:

That is seemingly not possible technically. The issue is that then Blender has to compare many many values to determine if they are the same or not, which is actually a slow operation. The design described in the task gets around this limitation.

Unity allows that, and it shows "--" when the values are different. It is quite handy to be honest.


An average does force you to go though all the values, but to test for the object being different may save some computation time?
When you say many many values, are we speaking of 100 or 1000 or more?

I just fired up my old and trusty Softimage 2015 because it had a very nice multi-select behaviour: If you select 2 or more objects with different attributes, it displayed an empty value for everything that wasn't set to the same value in all objects. If you now typed in a new value it set it to the same for all objects. BUT: if you entered something like "2+" it added 2 to all of the selected objects' property values. Very very nice. You could even enter expressions to e.g. randomize a value per object.

New to Blender but designed VR IDEs and 3D MRA packages.

Would nix the Opt/Alt key option because it forces the user to think if they want to edit multiple objects. The likelihood is that if they have selected multiple objects they want to edit the selected objects.

The experience just needs to indicate that the value varies across the selection set. Keeping the value of one of the selected infers that value has some kind of precedence. If it doesn't then the field can either be blank or show something like <multiple> to indicate that the field now spans multiple values.

Some choices are decoration in the field ( colors, <decoration>), or decoration on the field (border or badge).

The solution should take into account other indicators that may be needed in the future - ie It would be good to indicate if a value was being driven or had an equation, or was scripted.

Here are some variations showing how some choices, like using decoration for how value is derived means that option is out for indicating multiple selection.

ADA Section 508 sets standards for contrast and readability so the colors should be adjusted to meet that.

I appreciate how SoftImage ties the field colors to the axes. Reduces the cognitive load when trying to decide which field to change. Would like to see that implemented as a preference.

A few additional thoughts...

1st - When there are multiple selections many fields throughout the Number Panel and Properties will have differing values. Decorations per field is too visually noisy.
2nd - Use consistent visual affordances between places that indicate selection.


Maybe not a bright orange header, but that is the selection color.

3rd Make it apparent how value is being derived - like how keyframes show that a value is animated.


The current design, where animation colors fields makes it difficult to show other affordances since it uses several colors in tones that are hard to find complements for. so getting colors to go with the ones that fill fields for animation would need some work. If animation state could be switched to text color or a smaller decoration then giving equal weight to whether the filed is driven would be easier.

4th - Provide consistent interaction affordances across the app (not just the Number Panel)

@Karl Mochel (kalmdown) Of course, that is obvious. The difficulty of that is one of performance. Blender then has to compare many values to see if they differ or not. But, many other apps seem to do this with no issues, so it must be technically possible for us to do.

@William Reynish (billreynish) Looking at the space from the user POV (vs performance) - Do users want to have animation, driven, keyframed control for every property? If so, then they need the ability to control every property. To have control they can interpret with minimal error they need to understand the state of controls. One of the states of properties is multi-select - thus they need an experience that lets them understand any property that can be driven/animated when there is a multi-selection.

Additionally, the user works fastest if they understand all of the factors that affect a property. To do this, knowing all of the things which affect a property is useful. What things do they need to know that can affect properties? Animation, Drivers, Nodes and Code. Assuming these can be additive or override each other, what experience helps the user understand what is affecting a node? Currently, the system displays different states of animation or whether a property is driven, but not both. Going forward it would be good to be able to drive and animate plus have a nodes and code affecting the property - and know if the result was through these in combination or via overrides.

@William Reynish (billreynish) hmm, in editmode, transform pannel is already being calculated in realtime for milions of vertices


And its calculating mean value and not only checking if they are equal.

If it is causing editmode performance issues then that should be dissabled, if not then making same for object-mode shouldn't be a performance problem cause in editmode we have way more entities than in object mode.

@PawelP (Zuorion): Averaging is not the same as comparing. Anyway, this is more depending on implementation rather than a purely design issue.

William Reynish (billreynish) reopened this task as Confirmed.Feb 22 2020, 5:14 PM

During the recent UI planning session, we decided that we would like to tackle multi-object editing a different way than earlier proposed. This new solution requires bigger changes and is more work, but ultimately this way is simply clearer and more useful.

In the list of tabs, only properties sections are shown that are common among the selected items.

AutoCAD alike also use a similar concept for its properties dock which works relatively well.
They additionally have a dropdown menu on the top, which allows filtering by selected object type.
If you have a mixed selection of different types objects you can use the dropdown to select a certain type, and show only properties respective of that type.

This does seem better, but some notes:

Filtering these properties based on “Selection” versus “Active” does seem nice, but might highlight that some areas are not based on either, like “Render” and “Output”. Is is worth considering moving those out of Properties?

With the previous plan it wasn’t “clear at all to users which values work for multi-editing, and which values don't” and that part does not seem addressed here. So with multiple items selected, how are properties shown that cannot be multi-edited? Hidden would be problematic. Disabled maybe?

Some of the proposed behavior when values differ seem unclear. I worry that toggle buttons and Enums will appear disabled.

You show “horizontal ellipsis” on a differing-value color field, but that would indicate a following menu. Although that happens with those inputs – a color picker popping up – it does not indicate that the values differ. Perhaps a way to indicate "not a single color" with a color range or rainbow perhaps?

I realize that using “dash” as you propose is not completely unusual, but I find it too evocative of negation. Might be worth considering using "not equal" : ≠

Filtering these properties based on “Selection” versus “Active” does seem nice, but might highlight that some areas are not based on either, like “Render” and “Output”. Is is worth considering moving those out of Properties?

I should have clarified that. This would not affect those Properties sections.

With the previous plan it wasn’t “clear at all to users which values work for multi-editing, and which values don't” and that part does not seem addressed here. So with multiple items selected, how are properties shown that cannot be multi-edited? Hidden would be problematic. Disabled maybe?

The only reasonable way I can seem is to only show properties that are available on all selected items. Take the example in the task, where a Point and Sun light are both selected. Point lights have a Radius property, but Sun lights have an Angle property. If we react to the selection instead of the active item, we could either show both or none of those properties. Showing one of them doesn't work - it only makes sense when you use the *active* option. Showing none of them is much clearer, because they you know that everything you see can be multi-edited, and otherwise our layouts might also break if we try to merge layouts to show all properties.

You show “horizontal ellipsis” on a differing-value color field, but that would indicate a following menu. Although that happens with those inputs – a color picker popping up – it does not indicate that the values differ. Perhaps a way to indicate "not a single color" with a color range or rainbow perhaps?

I used that because it is a standard indication of this kind of state.

I realize that using “dash” as you propose is not completely unusual, but I find it too evocative of negation. Might be worth considering using "not equal" : ≠

I would much rather use an indicator that is standard across our supported OSs, rather than try and invent our own non-standard language that nobody would be familiar with.

The only reasonable way I can seem is to only show properties that are available on all selected items. Take the example in the task, where a Point and Sun light are both selected. Point lights have a Radius property, but Sun lights have an Angle property. If we react to the selection instead of the active item, we could either show both or none of those properties. Showing one of them doesn't work - it only makes sense when you use the *active* option. Showing none of them is much clearer, because they you know that everything you see can be multi-edited, and otherwise our layouts might also break if we try to merge layouts to show all properties.

Hiding properties and property contexts that only exist for a subset of the objects doesn't sound reasonable to me : that would mean the user can't add a modifier to an object even though it is selected and active, when their selection also contains objects of a different type that don't support modifiers (or support a different list of modifiers). It also means the user can't modify -or even see- a property of the same object for the same reason, ie it is not shared with all other objects in selection. This seems very error prone to me, and rather constraining : in order to do the actions outlined above, the user has to change selection state - keep only the active object in selection to edit its (unique) properties, or keep everything and be restricted to what they have in common, which can be a very small subset of all properties (for a mesh object and a curve object, that would happen to be only object, constraint and material properties - which means that the user would lose access to data, physics and modifiers contexts).
I hope this makes a good point against the 'hiding' part, but I second all the other aspects of this proposal : I think the improvements suggested are good, and clarifying the selection state in the properties header is a great idea. Hiding just seems like a regression and not really necessary.

@Hadrien Brissaud (hadrien) If set to use the selection rather than active, there *is* no active object to determine what should be shown. That's the whole point - to reflect what is selected rather than what is active. And for this reason, there is no way to show all properties - we can only show properties that are common. This means that you can also easily add modifiers to multiple mesh objects, and so on.

Hiding just seems like a regression

There is no real hiding going on. That only makes sense if you think of properties as always showing you options for the active object, which would not be the case here. Instead, it is showing what is available on both selected objects.

Any plans for multiproperties editing for every data type on the Sidebars of all the editors and modes? Nodes, video strips, track points, mask splines and points, Greasepencil layers, Fcurves and keyframes, NLA tracks and strips, plus the modifiers that some of them have, etc

When this is implemented, please add a toggle to affect active/entire selection by default on the splash screen like you have with the left/right click and space bar options.

Juan (jc4d) added a subscriber: Juan (jc4d).

@Wo!262 (wo262) yes, once there is a system in place for handling this, it should also be used for other places like the Sequencer, F-Curves. NLA and so on.

Little thought: would it be more clear if a math "not equal" symbol (≠) is used in not-equal fields when more than one object are selected?

@Lsscpp (lsscpp) I don't think it would, because the dash is a standard glyph used for this purpose.

Awesome to see this work! Copy to Selected has been a thorn in my side for all of time (I think i get the order wrong every dang time too).

Anyway, great work! One minor copy suggestion below.

This contextual info text felt a perhaps a little more complex than necessary (to me).
"Items that only exist on some of the selected items cannot be multi-edited"

Just some possible alternatives:
"Only properties shared between selected items displayed"
"Only shared object properties currently displayed"
"Currently displaying only shared object properties"
"Only shared item properties can be multi-edited"

Cheers!

This functionality already exists in blender. For example if you have one box with a x scale of 1 and another with an x scale of 0.5, if you select both objects (0.5 active) and change the value from 0.5 to 0.6, then pressing alt + enter changes the 0.5 to 0.6, and changes the 1 to 1.1 ( increasing both by the same value).

If you press alt when clicking into the box, then both boxes change to the same value after you press enter (without alt)

This functionality already exists in blender. For example if you have one box with a x scale of 1 and another with an x scale of 0.5, if you select both objects (0.5 active) and change the value from 0.5 to 0.6, then pressing alt + enter changes the 0.5 to 0.6, and changes the 1 to 1.1 ( increasing both by the same value).

If you press alt when clicking into the box, then both boxes change to the same value after you press enter (without alt)

Read the second paragraph.

Copy To selected doesn't work for UV Slots in 2.83, which is extremely annoying when I have to add UV's to multiple objects for editing their UV's in multi edit mode.