Page MenuHome

Handling Percentage Units
Closed, ResolvedPublicDESIGN


Related to

A large number of settings in Blender are conceptual percentages. They have a defined minimum and maximum value.

The Issue
The problem is that these percentage values are not handled uniformly. Some percentage values are represented as sliders, some as regular number fields. Some are represented in values from 0-1 and some are represented as values from 0-100.

Here is a small subset of the percentage fields in Blender:

Proposed Solution

  • Display all percentages uniformly
  • Always use sliders for percentages, because it makes the percentage visually clear and comparable
  • Use values from 0-100, and show the % symbol to let users know that it is a percentage

Implementation Issues
I think the main reason for using 0-1 instead of 0-100% is that values are stored as 0.000-1.000 internally? So, the question is, could such a conversion happen at display level?

Event Timeline

I'm fine with displaying them as sliders where appropriate, but I do not like using percentages at all, for a few reasons:

  • Using 0..1 is the standard in 3D editors, game editors, material editors, etc. We would be the exception here.
  • Float colors are also standard represented as 0..1, not in percentages?
  • For nodes, using a different value internally and in the button makes things quite confusing. As long as you only connect such percentages to other percentages it may be ok still, but in practice this will not be the case.
  • For rigging, drivers, shader writing and python scripting, there will be a similar confusion.
  • When exporting to other file formats, what is shown in Blender will not match other applications.

There may be a few cases where percentages would not harm, but I'm not sure what the rule would be to decide when to use one or the other.

@Brecht Van Lommel (brecht):

I don't quite understand all the arguments - perhaps it's a matter of coming at from different perspectives :)
Most apps that I've encountered use 0-100% values for things like opacity, hardness and other conceptual percentages. It's also a generally accepted and widely used method for describing relationships:

80% hot water, 20% coffee is clearer than 0.800 hot water, 0.200 coffee :) By using 0-1, it's not clear what the range is.

If you say something is 100% red, it means internally that red = 1. I guess that's ok

The only issue I see is with the nodes.

Perhaps it can be considered a unit conversion, similar to metric, imperial? Those have the same issues of being different from internal values, but more human understandable.
There could be a checkbox (on by default?) inside Units called Show Percentages. Then if you want a more 'raw' unit display you can turn it off.

For me the thing is, nodes or technical features like drivers are not an exception, they're very much at the core of Blender. If you hide what they really do and show percentages to make it easier to understand for people who aren't used to 0..1 ranges, that's not a good trade-off in my opinion. It makes working with some core components confusing. If you have to type in 70 in one place and 0.7 in another because one button type is a percentage and the other was not, that's problematic I think.

But this also follows from the fact that many of the values that you connect are colors, and expressing colors in percentages is misleading. Some colors like reflectivity have a clear range, but HDR colors are not limited by that, and it would be wrong to say that some HDR pixel has 200% red.

I can see that Modo uses percentages, but they don't have any node based workflow and seem to be the exception. Maya, Houdini, Nuke, Presto, Katana, Arnold, Renderman, V-Ray, .. those types of applications use 0..1, and if you're going to follow some standard, Blender is closer to them. In my opinion if the button appears as a slider, it's quite clear what the range is, no need to show as percentages as well.

No doubt displaying all these as sliders helps a lot. As you say, it gives a clear visual idea of what the range is. So we can certainly agree on doing that in either case.

I guess the thing is that it's already inconsistent with the current situation. Some areas use 0-1 while other use 0-100%. Particle Child %, Particle Display %, Render Size % and others use 0-100, while most of the rest use 0-1.

I think it'd feel strange to type in 0.3 into the Render Size % if you want a 30% size, much like I feel it's currently odd to type in 0.5 to mix two materials 50-50.

It's more of a philosophical difference. I think TD's will readily understand 0-1 whereas 0-100% is more artist-oriented.

2cents: for me as a blender user 0-1 range is always better

I don't think % would be better than using 0-1 for the reasons @Brecht Van Lommel (brecht) mentioned. I agree with using sliders for percentage values. I think as long as the UI element is a slider and it goes from 0 to 1 the user will quickly understand.

A way to make it more intuitive is to remove unnecesary decimals. Blender currently shows values as 0.100. The last 2 zeroes are only adding clutter. The UI should only show more decimals if they're not 0. So, instead of 0.500 we get 0.5 by default.

Optionally maybe if users type values higher than 1, they could be translated on the fly to floats. So type "30" and it becomes 0.3. Not sure how this would work with values that can be higher than 100% though.

@Diego Gangl (januz): Although it's always nice to think of ideas like those, I don't think it really makes it clearer. Typing '30' into a number field and having it convert to 0.3 will be really confusing. About turning 0.200 into 0.2, I'm not too fond of that either. It makes it look like it's only possible to have one decimal point, and if you have other values next to it that are 0.234 it quickly becomes inconsistent.

@Brecht Van Lommel (brecht): Ok, well, at least the sliders we agree on. What's your opinion on current percentages (0-100%)? Would you prefer to move those to abstract 0-1 too? It's not really clear to me why some values get to be proper percentages while other do not.

We could say that we use percentages for quality / resolution type settings.

@William Reynish (billrey): Yeah, converting would probably be confusing and hard to predict. I disagree on 0.200, it would still be consistent since it follows a logical rule. Any user that sees a decimal point will try to add more numbers at the end of it when they are tweaking a value. For example most percentage and pt values in Photoshop accept decimals but don't have ".0"s at the end.

@Brecht Van Lommel (brecht) makes sense since those settings aren't usually used in scripting, drivers, etc

Another thing, some sliders have scale issues. For instance the alpha value in the composite node goes up to 2.0, but takes any value when typed. "Fac" in Mix node goes up to 5.0 (it does what you'd expect until 1.0 then it gets weird).

@Brecht Van Lommel (brecht): Ok, to sum up:

  • Change all values with clear min/max to using sliders
  • Keep them in range 0-1, except if it's a setting that describes a % relationship of another setting (such as % of particles or % or render size etc)

I went through and changed all the 0-1 values with clear min/max to sliders, in this diff:

As a user as well as a developer I very much agree on all the points @Brecht Van Lommel (brecht) brought up against introducing percentages instead of 0-1 ranges.
Consequently, for the sake of consistency I think that it would be desirable to adhere to this 0-1 standard as much as possible, and only fall back to alternatives in places where it is absolutely the only logical choice to use something other than 0-1.

To realize this, there is yet another layer for possible intervention, that I think has been overlooked so far: Terminology.

E.g.: @William Reynish (billrey) brought up "Render Size" as a property where a 0-1 range would look odd, even wrong - and I fully agree!
BUT: We are not forced to stick to the term "Render Size"! :) There is a multitude of ways in which we can express that same idea,
that allow us to still use a 0-1 range without generating a conceptual dissonance between the label and the value.

Render Size Factor
Render Resolution Factor
Render Resolution Multiplier
Output Resolution Factor

(Now these are not my carefully thought out final suggestions in the sense of a proposal, but I hope it illustrates the point I want to make!)

To further push the idea of consistency we could even introduce a documented convention for such label->implied range terminology, which would benefit users, as they could pick up terms once in the user interface and recognize them in other areas, immediately empowering them to grasp the implied value range at first glance.

Possible guidelines I could think of:
"... Factor" = Indicate a value range of 0-1
"... Multiplier" = Indicate a value range of 1-[max] / alternatively: a value range of 0-[max] where [max] > 1

Bottom line: I think it is very well possible to realize some fields that at first seem to require a % value range as 0-1 fields, by working out different terminology, and through a unified terminology all over blender we could make the overall experience more consistent as a bonus.

Last remark: There will still be fields that call for a % terminology and value range, in those situations it will be plain obvious that only % makes sense, and as such I think it is also the right decision to go with % then. (e.g.: "Image quality" in %. Just works. :))

P.s.: I'd be happy to help on this (by designing/planning/coding) if needed :)

One last thing, so obvious that I even forgot to mention it:
As a matter of fact we already have such a convention widely used inside the Node Editor: "Fac"
So in that sense we can also look for and pick up such already existing conventions,
and rethink if they could be applied at a wider scale inside the application, transgressing the confined borders of the Node editor.

0-1 is standard everywhere and should also be standard in blender.
I often give my node groups math node and 0-10 or 0-100 range in sliders just because of 0.1 step when clicking arrows. Some values need only subtle change. And I love the way it works. With percentage range we simply lose that control.

Julian Eisel (Severin) changed the task status from Unknown Status to Resolved.Nov 30 2014, 3:44 PM
Julian Eisel (Severin) claimed this task.

Looks like the desicion has been made to leave everything as it is? -> closed!