List of Properties that should use the Units system #60824
Labels
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
No Milestone
No project
No Assignees
17 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#60824
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a list of Properties that should make use of units, but currently do not.
It is not exhaustive, but what I could find by browsing through the tools and properties. I can update this list if anyone notices any more examples.
Using consistent and correct units is a massive help for users, and makes it much easier to understand what values represent. We already have a nice units system in place - we just need to actually use it more.
Supported Unit Types
In Blender we support these unit types:
Additional Unit Types Needed
However, we have properties that are measured in units which we currently do not support, such as:
Operators
Randomize:
Shrink/Fatten:
Push/Pull
Shear
Smooth Vertex
Brush:
Properties
Eevee
Cycles
Bake:
Output:
Cache
Curves ObData
Bones ObData
Text Obdata
Motion Paths
Constraints:
Modifiers:
modifiers["Mesh Cache"].frame_start (Time)
modifiers["Build"].frame_start (Time)
modifiers["Build"].frame_duration (Time)
modifiers["Wireframe"].thickness (Distance)
modifiers["Shrinkwrap"].offset (Distance)
modifiers["Shrinkwrap"].project_limit (Distance)
modifiers["Ocean"]. frame_start (Time)
modifiers["Ocean"]. frame_end (Time)
modifiers["Wave"].time_offset (Time)
modifiers["Wave"].lifetime (Time)
modifiers["Wave"].speed (should be renamed to frequency)
modifiers["Bevel"]. width_pct (Percentage)
modifiers["Set Split Normals"].offset (Distance)
modifiers["Set Split Normals"].mix_factor (Factor)
modifiers["VertexWeightMix"].default_weight_a (Factor)
modifiers["VertexWeightMix"].default_weight_b (Factor)
Smoke:
Dynamic Paint:
Fluid:
Softbody:
Force Fields:
Particles:
Cloth:
Light Probes:
Materials / Nodes
Added subscriber: @WilliamReynish
One question here is, what do we do about percentages? There are hundreds of properties that should be percentages, but are displayed as 0.000 - 1.000. I much prefer the use of real percentages, and we have a system in place for it.
These are the main ones I could find so far. But I left or dozens and dozens of properties that should be percentages here. And It would also be good to get clarification on what to do for luminosity values. What can we do with those?
Added subscriber: @amdbcg
@WilliamReynish: I'm not sure about some of these.
Added subscriber: @fclem
@JacquesLucke
Added subscriber: @brecht
I think it would be useful if properties with the subtype
PROP_PERCENTAGEare automatically mapped from [0, 1] to [0, 100] in the user interface. Internal code doesn't really need the values in the [0, 100], right? Do you think changing this is feasible? @brechtA more accurate solution could be to display something like
Frame: 50 (2s)in the UI, where the actual time unit changes depending on the fps (I'm aware of the fact that this looks very ugly).I don't know what's the best solution...
I don't think editing [0,1] values as [0, 100] in the UI would work well. For animation, drivers, nodes, textures the values should be in the [0, 1] range, so there's a disconnect when you need to do something a bit more advanced. Users need to understand [0, 1] factors anyway, so hiding that only partially is not that helpful in my opinion.
We do conversion like this for angles in degrees and radians, and we regularly see users confused by it. In that case it's kind of necessary because degrees are better suited for common angles, and Python/math functions need radians. But for percentages it's not that bad.
We could have a frame time unit that always displays as frames, but still allows you to enter values in seconds.
Displaying the time next to it could be an option I guess, or maybe displaying it in the tooltip. I agree that hiding the discrete frame value would be problematic.
@JacquesLucke: Real-world time units could also just take the fps into account. In fact, it has to.
If you are using 24 FPS, frame 48 = 2 seconds. This is a very useful way to time things.
Displaying both the frame # and the real-world time seems unnecessary. It's the equivalent of showing all lengths in both Blender Units and whatever you set in the Units. We don't do this, and I don't think we should do that for time properties either. IMO all time properties should just show whatever you set in Units (Frames, Seconds, Minutes or whatever)
Well, currently it's not very clear. Some properties are float values, and others are values from none to full. These are conceptually percentages, and extremely useful for the user to know. A Weight of 0.500 is is ambiguous - the user can't infer what that means. But a Weight value of 50% is immediately clear. So I think this is actually a big deal.
I get the issue you are referring to, where the F-curves will map between 0.000 - 1.000, whereas the percentage value goes from 0-100%. But actually I don't see that as a problem at all. That's normal for any percentage in maths, so I don't think users will be confused by that. IMO it's better to use the correct and clear unit of measure (%).
@brecht, ok, I don't care too much if we use percentages or factors. @WilliamReynish previously said that he prefers percentages, so maybe you two should discuss that.
@WilliamReynish, yes but 2s will always be two seconds long, 48 frames will not always be two seconds long. To me that is a fairly big difference.
How would you type
frame 10into a field that shows seconds?And displaying
0.208333333sinstead ofFrame 5is not useful + what would happen when you want to increase the value by 1. Does it increase it by one second or 1 frame?@JacquesLucke First, by that logic, we could never use the time unit in Blender, because the values are all in frames under the hood.
Second, all of those issues exist for length-based units too.
If you change the Unit Scale, 1m is no longer 1m. In most animation projects, you don't change the fps all the time. You set it once and leave it for the entire project - just like the Unit Scale. It's the same thing.
Yes, seconds don't always map exactly to frames always, but that is the same as Blender Units that don't always map well to Imperial Units, for example. 1 BU = 3.28084ft But that's just how it is - not a problem as I can see.
So, frame 5 = 0.2 seconds. But that may be exactly what the user wants to know. Especially for motion graphics, dealing with real-world time units may be much preferable.
What we could do for better sub-second precision, is to do what Video Editing apps use do. They typically use*[Hours] [Minutes] [Seconds] [Frames]*
In other words, assuming a FPS of 24, frame 100 = 4s, 4f.
That is the equivalent of the Separate Units toggle for lengths.
Separating time units in seconds+frames could be an even better solution indeed. I wonder how that works with fps values like
29.97.We already solve that ambiguity by showing the button as a slider. I think that is immediately clear.
Using [0, 1] values is standard in computer graphics software, especially those that have node based systems and programmability. Percentages are just a different convention, they are not more correct.
For example color values are typically presented as [0, 1]. And if those then feed into shader nodes that uses percentages, you can no longer just copy/paste values, and you have to mentally convert between the two all the time. That mess can be avoided by just using the same convention throughout the application.
Currently at least, the slider is not the same thing as a percentage: It seems like we use the sliders to mean a useful min - max value, rather than an actual percentage.
Also, for me at least I don't find the sliders sufficient. It's often times very ambiguous even with them. Take the Simplify > Max Child Particles properties. This is displayed as 1.000. I often have to go and check if 1.000 means 100%. In this case it does. It would be so much clearer if it simply read 100% - it would be unambiguous then. Users wouldn't have to worry about 0.5 sometimes meaning 0.5 and other times meaning 50%. This is the ambiguity that would be great to resolve.
Lastly, what is the reason we permit the use of real percentages in the few places where we do use it? Why is it ok for the Render Resolution to be defined as a percentage and not 0.000-1.000? Because it is an integer?
I've separated the percentages to a separate todo.
We could start by addressing all the length, angle, pixel, mass and speed values.
Then we can handle the time properties, and last we can think of what to do with percentages.
Some ideas:
I'd like to use this task a a starting point for some new developers who to contribute a little bit of code to Blender for the first time.
I will make a public call on Twitter a bit later today.
If I find no one, I'll make the changes we agreed on myself.
@WilliamReynish, certainly there are some properties that are wrong now.
I wouldn't mind changing some "quality" type properties to percentages, as those are not animated/linked/textured. But for most of the list in the other task I still think we should use [0, 1]. We could have an option but it should be off by default.
@brecht @JacquesLucke Ok, so we agree to:
The nice thing about the above, is that at least then everything is set correctly in RNA and the UI can the interpret that in various useful ways.
ok?
Fine with me.
Added subscriber: @rjg
Added subscriber: @FloridaJo
This comment was removed by @FloridaJo
@FloridaJo These are defined in what Blender calls RNA in C, not in the Python UI. The RNA files are in source/blender/makesnra/intern
@FloridaJo, often it is a good idea to just do a full text search for the property name or its tooltip to find where it is defined. (or for some other property that is closely related, often they are defined in roughly the same place)
Added subscriber: @Poulpator
I have submitted a diff for cloth properties here D4260, first time i contribute so let me know if i'm doing something wrong
Added subscriber: @LukaszKwoska
Hi guys. I've created revision for shrinkwrap modifier. https://developer.blender.org/D4261
Would you prefer to get single revision for multiple positions from the list above, or multiple separated by context? Particles/Modifiers, etc?
@LukaszKwoska, while I'm happy you want to help, I would like to not finish every just now so that maybe other can give it a shot as well.
Let's at least wait until monday. Then feel free to make a patch that contains fixes for multiple contexts.
In the meantime you might want to take a look at this list: #56950
Those tasks are a bit harder, but should still be achievable.
Added subscriber: @zeauro
I am against the idea to convert every numerical value setting normalized between 0 and 1, a percentage look.
Sometimes, pertinent range, when a significant change occurs, is a tenth. Sometimes, it is an hundredth. Sometimes, it is a thousandth.
When the tweak needed has to occur at the fourth digit after coma, presenting things as percentages does not help at all.
I also don't think that expressing key values as portion of seconds is more meaningful for user than a frame number.
An approximation in time may be visible in tooltip according to frame rate.
A automatic conversion from typing 10s to frame 250 may help.
But nothing can be more accurate than frame number.
Well, we would not be getting rid of frames, obviously. I think the default display should be in frames. But, currently, if you want to, say, make sure your shot is exactly 10 minutes long, you can't easily do that. You'll have to type in 106060*[fps]. This is very clumsy, and slow if you want to tweak or change it.
It could also be that you would like to make the life of particles last exactly 2 mins and 30 seconds. That's also a pain currently to input.
This is exactly the same use-case as for length units. Some people also argued that we should not include the ability to use real-world units for lengths. In the end, using real-world units makes things easier to understand and use, and much faster too, esp if you want to type in time lengths in minutes or hours. You don't have to do back-of-envelope calculations all the time.
As for percentages, we agreed above to display factor values by default as 0-1 still, but with an option in the Units panel to display them as percentages. However, your argument makes no sense. You can have percentages written out as 100.0% or 100.000% if you need. That's no issue.
With the option to display factors as percentages, if nothing else, I expect we will discover loads of places where prop_factor should be used but currently is not.
Shutter time is not a typical time unit.
@brecht: What is shutter time in then? I thought it's the time (in frames) in which the shutter is open?
Same for Rolling Shutter Duration. That is also a time unit. How is it not?
So I don't get that. In what way are these two properties not measured in time?
Added subscriber: @MarceloGomez
Added subscriber: @ChristopherAnderssarian
It is and isn't a measurement of time. (Note that Brecht said: typical time unit)
"It's a measurement of time in relationship to the frame rate."
The proper measurement (and unit) is Degrees. This video explains it.
We could measure the shutter in degrees, and that might be nicer, but the actual, current property value is a measurement in time. All our time properties are currently measured in frames, and so they are all relative to the frame rate - so this is no different.
@JacquesLucke Absolutely. Right after sending this comment I thought exactly this. Thanks for #56950. That's what I wanted to ask for.
This comment was removed by @FloridaJo
This page explains the process of creating a diff. It's the same for Linux and Windows.
Added subscriber: @Rickyx
In the initial list, in Properties -> Output
image size could be added:
It is currently labelled Resolution, the unit of measurement of which is dpi
and should be called Size, expressed in px.
I reported it on:
https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/1315
and I have submitted a patch (my first):
https://developer.blender.org/D4253
The patch deals just with the UI part, not with the python property (I suppose it may cause incompatibility with some addons).
This comment was removed by @FloridaJo
Removed subscriber: @Poulpator
This comment was removed by @FloridaJo
@FloridaJo That's just the hash of your local commit, Jacques won't be able to commit any code with that. It seems you have some trouble with the process so let me try to explain it to you. The reason this is done with git even for two lines of code is to have a consistent and predictable end result when you've got several people working on the project. So let me walk you through the steps (some of these may be obvious to you, but just I'll write them down anyway in case this is something you're unsure about).
cdfollowed by the directory name.git clone http://git.blender.org/blender.git. This creates a local copy of Blenders code and allows git to track both your local changes and the ones contributed by other developers. If you want to update your local repository you can usegit pullto pull in the lastest changes. When you clones the repository you are on the master branch. You can think of the git repository like a tree, the master branch is the trunk and when you want to develop features based of the master you can create a new branch. The branch uses the master as a starting point, but all code changes of the new branch don't impact the master until you merge the changes back (that has to be done manually). So if you want to create a patch, it's a smart thing to create a branch for it, just to be safe that you're not creating any conflict. BTW you can't directly push changes to the remote Blender master branch anyway, this is for the core developers only. That is why you've got to upload a diff, but more about that later on.git checkout -b some-new-featurewhere some-new-feature can be any name you want. This command creates a branch and switches to it. You can view your local branches withgit branch, the current branch is marked with an asterisk*. You can view all branches including the remote branches on Blender's server withgit branch -av.git add /path/to/changes/file.cto stage files that you'd like to commit (replace the path with the actual path and filename that you have changed). Once you've done this for every file you cangit commit -m "text explaining why and what you've changed". Once you've run this command you have stored your changes to your branch locally.git diff master..some-new-feature > some-new-feature.diffcompares the code of the master branch against a branch called "some-new-feature" (replace it with the actual name of your branch). The differences, hence the name for the diff command, are written to a file using a redirect>of standard out (stdout) to a file calledsome-new-feature.diff. You can add a path in front of the filename because you'll likely don't want the diff file in the git directory.rB Blenderin your case). You'll have to confirm your changes and if you know who is maintaining the specific project your want to contribute to, you can add them as subscribers. Once this is done it may take a bit for other developers to verify you changes. If they aren't happy with your changes, you may have to update your patch and they'll review it again. When everything looks good, they'll commit it to the right branch in the blender repository.git checkout master, pull the latest changes, switch back to your feature branch usinggit checkout some-new-featureand then rebase usinggit rebase master.I hope this helps.
@Rickyx I think 'resolution' is actually the correct term. Changing these values doesn't change the size, and doesn't change what you see, but the amount of pixels used to describe what you see. You get the same image but with more or less pixels defining it. That is what resolution is.
A 27" TV which is 4K has higher resolution than a 27" TV which is HD.
Size is has to do with how you are viewing your image. You can view a 320*200 image in an IMAX theatre. That is a huge size but low resolution.
Resolution is how many pixels are used to describe an image. An 8K image displayed on a postage stamp is tiny, but has real high resolution.
This comment was removed by @FloridaJo
This comment was removed by @FloridaJo
@FloridaJo Have you tried building it from the console using
make? This will give you a detailed output on what went wrong.This comment was removed by @FloridaJo
@FloridaJo, please ask for help on IRC or on devtalk.blender.org when you have build problems. This task is not the right place.
To clarify my thinking on the time and factors, here's what I think we could do:
Add two options to the Units panel - Separate Time Units and a 'Factors' setting:
When Factors are set to Percentages, all factors are displayed as percentages, like so:
When Time is set to Seconds, we display the time units in Seconds. The Separate Time Units shows both minutes, seconds and frames, similar to how Separate Length Units works now:
I would like to add my 2 cents here on the debate.
As Brecht said about graphics, 0-1 is the common factor.
.566 makes more sense than 56.6 %
As for shutter speed, it is fractions of a second. (ie. 1/500 shutter speed )
This guys says it well here on shutter speed for video:
"For example, when shooting at 25fps, your shutter speed should be 1/50 of a second.
If your camera can shoot at 50 or 60 fps, your shutter speed should be 1/100 or 1/125 of a second.
The reason for this 180-degree rule is because it helps us to record video that contains natural movement.
If the shutter speed is too slow, you’ll get blurred movement, if you shoot at a shutter speed that’s too high,
everyone in your scene will look like robots or as if they were recorded in stop motion.
Sticking to the 180-rule will give you the most natural movement." - Jon Devo
As for bloom radius:
From what I've read it is some form of Gaussian Blur
or Multiple Gaussian Blurs blended.
The radius for Selective Gaussian Blur in Gimp
has a tool tip that says:
"Radius of a square pixel region,
width and height will be radius*2 + 1."
Maybe that helps.
Yes, absolutely agreed, it would be nice to change the shutter to be in degrees rather than in frames. This is how you set the shutter speed in film cameras.
A 180 deg shutter is more correct that a 0.5 shutter.
Added subscriber: @frameshift
I'd like to mention one that's been confusing me forever.
Randomize Transform has meters as the unit for location and scale. For location this makes sense, but for scale I feel it doesn't.
Also, if I understand it correctly, setting this number to 1.15m would set the boundaries for the randomisation to 85% - 115%, which is not very clear in this UI.
I would like to propose two fixes for this:
@frameshift Yes, that's true. That seems like a mistake. I added it to the list.
As for your proposal on how Randomize Transform works, it's outside of the scope of this task. This is just about giving values the correct units.
In the description we refere to "Common measurement".
The chosen physical units of measurement are practically all part of the International system :
ampere, kelvin, second, metre, kilogram, candela, mole.
Many of the derived units also adhere to the standard, used in most countries ( all except US, Liberia and Myanmar ).
Can the intention to take this standard as a point of reference (and, for example, use the Celsius degrees) be made explicit and be used everywere it is possible?
The Smoke Density you are referring is the density in smoke behavior?
The same word is used in principled volume and refers to smoke optical properties ( that may or may not be related to the mass of the smoke ):
in that case we should or use a proper scale ( Bacharach, Ringelmann, ... ) or using trasmittance in relation to density (mass).
Or having two different names?
The main thing for the units is for them to be convenient to users, if they can be SI units even better but I don't think it's a hard requirement.
The smoke density unit is actually 1/m, fixed that in the table now. It's a little confusing with standard physics "density", but common terminology in computer graphics.
It’s not a hard requirement, but this task was meant to illustrate the missing unit types corresponding to property values we already use.
Physical properties without specified units makes them much harder to set.
We could also add more unit variations to the units we already support, such as using Lumen as well as Watts for lights.
As for smoke density, I think you are right.
I'm sorry being so precise, I'm trying to contribute...
For smoke behaviour the correct unit IS kg/m³: the fluid moves up or down because of his density (but says nothing about his appearance). This is related with the temperature diff. params (witch should be a delta).
For smoke optical density, in shaders, the correct unit should be trasmittance T ( if it is the way the shader has been coded ).
For light Lumen -luminous flux- cannot be converted in Watt -radiant flux-, as those units describe different quantities: the chosen unit should be in accordance with the code of the emitter.
I suggest that using preferably SI may appreciated by users who approaches blender (and can find on wikipedia the quantities expressed in a consistent way): many simulation packages use this approach.
Thank you,
Riccardo
The volume density that the task above refers to so far is for shaders, and there it is an attenuation coefficient with unit 1/m. There may be other settings in the smoke simulation that need different units, that would need to be figured out property by property. There may be one that has unit kg/m³, or maybe the density is specified indirectly through other properties.
For lights, it can be useful to be able to specify the Lumen exactly, taking wavelengths into account. However there are shader nodes or light shapes for which we can't efficiently predict the effective luminous flux, and it's often not convenient or incompatible with other CG software. In that case we might still use a Lumen unit that is correct if you assume e.g. a white light without textures, and consider the color to be a multiplier on top of that.
Thank you for clarifications.
Added subscriber: @padthai
Hasn't the bevel amount one been changed?
Removed subscriber: @frameshift
Added subscriber: @HDMaster84
What about the new mantaflow simulation, cloth simulation and softbody simulation? All of those are missing units. (I get that they don't really do physically correct stuff but there could be an effort to make it understandable to a physicist looking at it)
What about a unit for pressure? We could add hPa or bar (smaller more natural numbers) to be the pressure unit for metric.
@HDMaster84 Yes, those values should use proper units ideally.
Added subscriber: @ThatAsherGuy
Re: Shearing. The value that we use for shearing is the shear factor, which doesn't need a unit on its own. It maps nicely to modal mouse input, it's great for quick/arbitrary shears, and advanced numeric input lets us input the factor as
1/tan(radians(90-θ))when we need a precise shear angle. We could add a property to the shear operator that switches the input mode from factor to angle, saving users a dive through the manual, but that's out of scope for this task.This issue was referenced by
36aeb0ec1e