Presets for scene units
AbandonedPublic

Authored by Campbell Barton (campbellbarton) on Feb 14 2016, 4:02 PM.

Details

Summary

This patch adds simple preset menu for unit scale scene property. As illustrated below:

GIF animation:

Comparison between old and proposed Units Panel UI:
Left-old, right-proposed.

Issue with current UI is that it's quite obscure comparing to other 3D software:

As you can see other software that supports multiple unit systems provide users with clear and intuitive list. Blender has only float property which does not even indicate itself very well, so users just ignore it and continue to use default unit scale, even if they work in smaller scales.

For example: jewelry and product designers work with millimeters, but default scale for metric system is meters, so in this case all default primitives created with enormous sizes, which continuously frustrate users, because they have to scale them down every time.
And don't think this is a newbie problem, I personally know professionals who work with Blender for more than 5 years, and they had no idea they could work on millimeter scale.

Ideally it would be better to get rid of current float slider and use enum list only, providing users with float slider only if they chose to use custom scale (like in other 3D software), but I guess that will create compatibility issues. So preset menu is the second best choice in this situation.

Diff Detail

Repository
rB Blender
Mikhail Rachinskiy (alm) retitled this revision from to Presets for scene units.Feb 14 2016, 4:02 PM
Mikhail Rachinskiy (alm) updated this object.
Mikhail Rachinskiy (alm) set the repository for this revision to rB Blender.

I am also considering a different approach, illustrated in animation below:

In this case we have only one set of presets, UI looks more like other 3D software, and I think overall it's more convenient.
But mixing imperial and metric units in one list with alphabetic sorting makes me wonder if that is acceptable?

Campbell Barton (campbellbarton) requested changes to this revision.Feb 15 2016, 10:31 AM

Generally fine, but theres currently no way to add presets, see how AddPresetRender works.
This should be added to presets.py too.

This revision now requires changes to proceed.Feb 15 2016, 10:31 AM
release/scripts/startup/bl_ui/properties_scene.py
30–41

These menus can have their own description, which will show in the tooltip.

Currently we don't use this very much, however in this case I think its worth explaining exactly what the presets do...

eg:

class SCENE_PT_unit_presets_metric(Menu):
    """Explain how this setting is used in some detail"""
    bl_label = "Unit Presets"

I am also considering a different approach, illustrated in animation below:

In this case we have only one set of presets, UI looks more like other 3D software, and I think overall it's more convenient.
But mixing imperial and metric units in one list with alphabetic sorting makes me wonder if that is acceptable?

Think this is good and probably most users would prefer, since you can quickly set the preset and not care about details.

However we also have multiple kinds of units (for now only distance and angle... and we don't need to bother with having angle presets).
But at some point we may have time as a unit.

So suggest to future-proof this by using preset_subdir = "units_length", so later we can have units_time... or whatever else.

Update diff according to given remarks. Also update UI for Units panel, to make it look less alien.

I hope it wouldn't hurt if I update the UI for Units panel? The person who did the original design during 2.5 refactor project clearly did not look how other software handles same UI, so he made it look closer to 2.4 UI.
Also hide unused elements is not great user experience, grey them out instead.

  • Use unit type prefix so presets are ordered by imperial/metric
  • Expand unit None/Metric/Imperial (takes up same amount of room)

Expand unit None/Metric/Imperial (takes up same amount of room)

Can we please not do that? I understand visual sacrifice in favor of efficiency when this can speed up workflow, but these are unit settings—you set them once, and then forget about it.
I specifically focused on minimalism and comprehensiveness of the UI, I tried to give user only necessary information as structured as possible, and expanded menus just break it.

These are very good changes @Mikhail Rachinskiy (alm)

I hope it wouldn't hurt if I update the UI for Units panel? The person who did the original design during 2.5 refactor project clearly did not look how other software handles same UI, so he made it look closer to 2.4 UI.
Also hide unused elements is not great user experience, grey them out instead.

I also prefer this approach. It's much cleaner and simpler to choose your unit of preference. It also keeps the length and angle units more clearly separate.

Use unit type prefix so presets are ordered by imperial/metric

Is there a possibility to sort preset list without using prefixes? If not, then I still prefer alphabetic sorting over long prefixes, which add to much noise and make searching for the right item even harder.

Also repetitive information is very bad for UI design.

@Mikhail Rachinskiy (alm), have slight preference for ordering by type (just seems a bit strange to have miles next to millimeters)
It does look a bit strange when you have picked, but means the menu items are ordered more usefully.

UI team may have input - @Jonathan Williamson (carter2422) (and others from the UI team), what do you think?

I agree with both of you, @Campbell Barton (campbellbarton) and @Mikhail Rachinskiy (alm). The prefixes reduce readability but improve organization.

How about this: group Metric and Imperial units separately in the menu, sorting each group alphabetically. For example:

  • Feet
  • Inches
  • Miles
  • ---
  • Centimeters
  • Meters
  • Millimeters
  • Kilometers

Or, grouping and sorting by size (makes even more sense to me):

  • Inches
  • Feet
  • Yards
  • Miles
  • ---
  • Millimeters
  • Centimeters
  • Meters
  • Kilometers

@Jonathan Williamson (carter2422).

Its possible but means we would have to either hard-code preset menu (which is a bit weak), or support passing in custom groupings (possible but a bit messy and complicates Menu.path_menu).

A simpler alternative is to use this patch (with prefix), but change the draw code not to display the prefix.


This comes from attempting to store 2 kinds of presets in one menu.

Maybe we could do something closer to what we had originally - you choose metric, then presets are shown only for metric.


Another option is not to attempt to use a generic preset system, then we can arrange things how we like, but means users wont be able to add their own so easily (which may be acceptable in this case)

Maybe we could do something closer to what we had originally - you choose metric, then presets are shown only for metric.

Seems like a reasonable compromise to me.

Another option is not to attempt to use a generic preset system, then we can arrange things how we like, but means users wont be able to add their own so easily (which may be acceptable in this case)

What do you mean by "generic preset system?"

Another option is not to attempt to use a generic preset system, then we can arrange things how we like, but means users wont be able to add their own so easily (which may be acceptable in this case)

What do you mean by "generic preset system?"

AddPresetBase and Menu.draw_preset, so you can use a directory of files for presets.

I think that unit presets are a waste of vertical space. We have unit presets, then below it the length system. Organize them into one. There are two places that influence each other which is a cyclic dependency. Also the preset value will show you a deceiving information - getting out of sync of what is really going on in the scene. Take for instance the dimensions panel in the render tab. You pick a preset then you can modify it bellow. That's OK for tweaking - however there is no feedback in the preset list that the default values aren't used in the scene anymore. Not only the resolution but also the screen ratio - for instance a 16:9 could be a 4:3 in reality or whatever else. The problem is in perception. There is a reason why marketing has all those 9.99, 299.99 etc prices. Our brains rounds up numbers at first value. So you'll think that's 9 bucks or that's 200 bucks and I still do that from time to time until the brain kicks in and say hey man, add one.

Here you'll look at that 1080p and often not noticing the change if it is small enough. Because it is not a preset it's a starting point. At least color it red or add a small warning sign that the preset is altered bellow.

Also Value ladders. That patch was on hold until the multiedit was done. For instance you pick a Lenght > Metric then right click on the list field and set the ladder to centimeters (0.01). Then the preset will go > Metric (centimeters). That would make consistent with the rest of the blender value fields when the patch is implemented. For imperial i don't know - make it just names without values. I don't know how many badger's teeth are in a fox tail whatever it is used. :P

The unit presets here and elsewhere in the blender ui needs a bit of thought. Adding an another semi broken thing from a design standpoint is not a solution.

It would make sense to switch the vertical order of None/Metric/Imperial and Degrees/Radians (or whatever we go with) - this would put None/Metric/Imperial right next to its modifying options. It's always better to keep the closest-related options as close together as possible.

This comes from attempting to store 2 kinds of presets in one menu.
Maybe we could do something closer to what we had originally - you choose metric, then presets are shown only for metric.

Seems like a reasonable compromise to me.

This is not the issue, the issue is—alphabetic order, and splitting one list in two does not solve it. As Campbell said, we could just accept limitations of the current preset system if UI is not terribly unusable.

No prefix for list items

release/scripts/startup/bl_ui/properties_scene.py
30

Menu should be use naming convention SCENE_MT_units_length_presets

Seems OK, though don't have a strong opinion @Jonathan Williamson (carter2422) ?

This revision is now accepted and ready to land.Mar 23 2016, 2:19 PM

Change class name to SCENE_MT_units_length_presets

Additional class naming changes

Looks good to me, much clearer. +1 !

If other devs and @Jonathan Williamson (carter2422) are okay this could go to master.

I'm happy with this now. Big improvement over status quo.

Ah one quick change @Mikhail Rachinskiy (alm).

In the presets it should be Feet rather than Feets. There's no 's' for the plural.

Committed rB7f3da8f5c91e5dbf030b938a5d852ebc9ce6b361

Relocated "units/length" -> "units_length", since slash direction may give issues on windows and its easier if we keep these dirs flat.

Hey all,

This isn't technically a bug so I figured this was the correct place to put it, but I'm happy to make a new thread if needed.

I realise that I'm a little late to the party on this one but I think some changes need to be made to the presets as there are some major issues with scene units when switching between presets that should be compatible.

  • When switching between presets the 3d grid changes size dramatically and always gets badly clipped.
  • The size of existing objects within the scene change relative size when switching between presets which makes it impossible to change between unit types mid project without tweaking the unit scale or scaling the object. (i.e. a cube that was originally 2m³ becomes 2cm³ or 2mm³, rather than 200cm³ or 2000mm³ when switching from metres to cm to mm).
  • It's been the de facto standard for years that the default sizing of objects is 2m³ and this change breaks that convention. It would be better imho to retain the 2m³ sizing for new objects and have people scale the object after the fact or at least have the option to retain relative sizing when changing the unit scale?

Thoughts?

@Andy Davies (metalliandy) hi Andy, this thread is about making Units UI comprehensible, so users could figure it out without first searching for a tutorial on YouTube.
Your complain is about the Unit System itself. Of course presets are basically just py scripts and we can do what ever we want, like change the scale of all objects in the scene to preserve their size in units for eg., but to me it looks like an insane idea.

It seems like the person who implemented the unit system in Blender 2.5 did it the easy way and without looking into other 3D packages (like Fgons in 2.4). He created an alias system where chosen units are displayed in the UI (Location, Dimension properties and Grids), but under the hood it still just generic Blender units, and by changing the units settings we just change aliases:
1 BU = 1 Meter
1 BU = 1 Millimeter
etc.

That's why objects "change their size" with different unit presets—because actually they don't.
That's why if you use feet for scene units, and move your object by typing 1 on your keyboard, object moves not for 1 feet, but for 3.657 feet—because 1 BU = 3.657 Feet.

So to all people who want better Unit System for Blender: stop proposing improvements for the current unit system, Blender should be cleansed from this filth and have a new unit system with thought out and robust design.

As for now just skip this crap.
Problems and confusion—that's the only thing the current unit system can offer to you.

@Andy Davies (metalliandy) hi Andy, this thread is about making Units UI comprehensible, so users could figure it out without first searching for a tutorial on YouTube.
Your complain is about the Unit System itself. Of course presets are basically just py scripts and we can do what ever we want, like change the scale of all objects in the scene to preserve their size in units for eg., but to me it looks like an insane idea.

It seems like the person who implemented the unit system in Blender 2.5 did it the easy way and without looking into other 3D packages (like Fgons in 2.4). He created an alias system where chosen units are displayed in the UI (Location, Dimension properties and Grids), but under the hood it still just generic Blender units, and by changing the units settings we just change aliases:
1 BU = 1 Meter
1 BU = 1 Millimeter
etc.

That's why objects "change their size" with different unit presets—because actually they don't.
That's why if you use feet for scene units, and move your object by typing 1 on your keyboard, object moves not for 1 feet, but for 3.657 feet—because 1 BU = 3.657 Feet.

So to all people who want better Unit System for Blender: stop proposing improvements for the current unit system, Blender should be cleansed from this filth and have a new unit system with thought out and robust design.

As for now just skip this crap.
Problems and confusion—that's the only thing the current unit system can offer to you.

Fair point. It needs a redesign for sure I think :)

Out of curiosity, which 3D animation packages do not use an alias system for units, and actually work fundamentally different than what Blender does now?

@Brecht Van Lommel (brecht) It's Maya.

Here is GIF animation to illustrate how it works:

As I understand it the thing being requested by @Mikhail Rachinskiy (alm) is a display / text entry unit. So setting that "display unit" to e.g. mm instead of m would ensure that:

  • Values are displayed in mm rather than the current automatically defined "best fit" unit. So it would display 1000mm rather than 1m (while perhaps still switching to another unit if there are too many zeros?).
  • Text entry of a value without a specified unit would be interpreted as mm, so entering "1000" would give you 1000mm rather than 1000m.

That can be an additional setting that works orthogonal to the scale setting (I think called "system unit" in some other apps). This scale / system unit is used to define how 1 blender unit maps to other units. If the display and system units are too different you get floating point precision problems, so you need that system unit control to work with astronomical or microscopic scenes.

Besides that there is the issue of the scale affecting the grid and newly created objects mentioned by @Andy Davies (metalliandy). If I remember correctly this has changed multiple times, with some users wanting it to be affected by the scale setting and others not. And there's some other confusing behavior as mentioned in T42263.

Overall I don't think any of this requires a rewrite. There's a few separate issues to improve within the current unit system, and they get easily conflated in discussions to make it seem like the whole system needs to change, but really they are unlikely to be big code changes.

@Brecht Van Lommel (brecht) it is not enough information to be sure if it is what I have requested.

  1. You did not explain how this change will work with BU, for e. g. what will happen when user will set scene units from m to mm? 1 m = 1 BU and 1 mm = 0.001 BU?
  2. If so, how transform tool input will respond to that? Will keyboard input for Translate tool convert "display unit" to BU?
  3. What will happen during geometry export to interchange formats (obj, stl)?

@Brecht Van Lommel (brecht) it is not enough information to be sure if it is what I have requested.

  1. You did not explain how this change will work with BU, for e. g. what will happen when user will set scene units from m to mm? 1 m = 1 BU and 1 mm = 0.001 BU?

The display unit would not affect the mapping to blender units, only the scale / system unit setting would. So if you would leave the scale to 1.0 it would work as you say.

  1. If so, how transform tool input will respond to that? Will keyboard input for Translate tool convert "display unit" to BU?

It's handled by the same code as text entry in buttons as far as I know, so I imagine both would work the same.

  1. What will happen during geometry export to interchange formats (obj, stl)?

The addition of a display unit would not be change anything about import/export.

@Brecht Van Lommel (brecht) then yes, if we're not leaving Blender ecosystem, it will do very good.

But...

The addition of a display unit would not be change anything about import/export.

Then here is a serious issue: if 1 mm = 0.001 BU when we export 1 mm model to stl file, and then import it to Rhino or Magics (with mm as default scene unit), model dimensions would be 0.001 mm, not 1 mm.

Same goes for Maya, where cm is a default scene unit.

That means that all export scripts should automatically convert unit scale to match arbitrary unit to scene unit.
Import scripts should have this option too, or else 1 mm model from Rhino will turn into 1 m model in Blender.

Just a side note: please do not worry about STL or OBJ, those formats are unit less, they do not define any default unit. So it’s up to user to set proper scaling factor in exporter's options to convert from BU (aka meters) to whatever unit s.he wants to use.

@Bastien Montagne (mont29) that precisely was my point. All I/O add-ons should be updated in order for Blender's "Display Unit" to work in pipeline with other DCCs.
I'm sorry I did not make that clear.

In order to add full support for international unit setup, there are some other requirements.

Note: allready posted this on bf-funboard.

When working with "real-world" sized models, hardcoded default values may only match either SI or Imperial.

Yep and what's the issue ?
An object wih default in 1m SI should make 3.281 foots at creation time, so overall size remains constant across system units. Currently this is not the case.
This will only apply to Float/FloatVector property with "LENGTH" type set.

There is two way to handle this properly:

1 Blender's property side.
In order to natively solve such issue we should have a default unit setup as per addon basis / or by property, and convert default/min/max values according on read.

Without either setting for units or scene unit system set, conversion can safely be skipped.
Should not impact performance as it only apply on read.

2 Python side.
Hacks to handle such conversions on the python side require adding a multiplier variable on every default values and wont dynamically work on unit change as default values are not set at runtime.

Proposed workarround:
adding get_default / min / max callbacks to handle this dynamically on python side at runtime.