| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Some statements were split across multiple lines because of their
trailing comments.
In most cases it's clearer to put the comments above.
|
|
This adds a space between a value and its short unit name except for foot, inch, degree, arcminute, arcsecond
Differential Revision: https://developer.blender.org/D5051
Reviewed by Brecht Van Lommel
|
|
Now when using imperial dimensions,
using 'm' suffix is treated as meters instead of miles
(use 'mi' or 'mile' instead).
Resolves T65731
|
|
Quiet extra-semi-stmt & missing-variable-declarations
|
|
Prepare for enabling ReflowComments.
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
To distinguish mW and MW without having to deviate from the standard
SI unit abbreviation. For all other units there are no changes.
|
|
This affects point, spot and area lights. Sun light strength remains without
a unit. This change does not affect .blend file compatibility in any way, as
with the rest of the unit system it's purely a display and editing feature.
Not used for Cycles yet, that will be done after unifying the settings with
Eevee.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
Needed for clan-format not to wrap onto one line.
|
|
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
|
|
For clang-format not to wrap definitions.
|
|
Allows expanding tabs before running clang-format.
|
|
|
|
|
|
|
|
I only specified the identifiers for the units that are actually accessible for now.
This way we can postpone some decisions for now. E.g. if it should be `METER_SQUARE`, `SQUARE_METER`, `METER_SQ`, ...
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3945
|
|
Continuation of https://developer.blender.org/D3802
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3808
|
|
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3766
|
|
|
|
Users can select the main unit they want to use now.
Previously the displayed unit always depended on the magnitude of the value.
The old behavior can be restored by switching to the "Adaptive" mode for length, mass and time units.
Meters, kilograms and seconds are the default units for new and old scenes.
The selected unit is also the default unit for user input.
E.g. if cm is selected, whenever the user inputs a unitless number into a field of type length, it will be interpreted as cm.
Reviewer: brecht
Differential: https://developer.blender.org/D3740
|
|
Differential Revision: https://developer.blender.org/D3719
|
|
This is still far from prefect, but yet much better than what we had so
far (more consistent with inheritent precision available in floats).
Note that this fixes some (currently commented out) units unittests, and
requires adjusting some others, will be done in next commit.
|
|
* Numbers with units (especially, angles) where not handled correctly
regarding number of significant digits (spotted by @brecht in T52222
comment, thanks).
* Zero value has no valid log, need to take that into account!
|
|
Also make return args explicit.
|
|
|
|
'1mm+1m' would fail with original fix, now consuming all alpha chars before checking unit again...
|
|
`m` unit when used after `cm`/`mm`/etc. ones would get ignored, and the alt version of miles
would be used instead.
The root of the issue is that, in `unit_find_str`, once we get a 'hit' for a unit, we check
it's actual unit (since 'm' would also hit on 'cm', 'mm', etc.). In case that hit is not a
valid unit one, we would just return NULL, breaking the cycle of checks over that unit, and
hence missing all later usages of it.
So now, in case we have an 'invalid unit hit', we immediately retry to find it within remaining string.
|
|
|
|
It would simply remove default units (in most case), cannot see any good reason for such behavior?
Might work in case default unit is the only one present, but breaks consistency (and it may not be
always obvious for user which unit it is). Comes from original patch from five years ago, rB7d8f0fce.
This will break keyboard-setting of values, e.g. '2m 33.4cm' would become '2 33.4cm',
totally useless and invalid entry!
|
|
Our 'unit epsilon' was too small, given the fact we only display up to four digits usually...
|
|
|
|
use when the length of the destination string is needed.
|
|
unit.c intentionally doesn't include DNA or BKE headers (except its own)
|
|
assumes translations are in meters.
Turned out there were several issues in handling of scale parameter by numinput.
Fixed that by factorizing more some code in common with 'usual' numbuttons eval code
(new `bUnit_getScaleUnit()` helper will return valid scaled value, depending on
given system and type).
Now, numinput behaves as expected - using default unit amended by scale in case no unit is given
(i.e. entering '20' with a scale of 0.01 will give you 20cm, and '20cm' as well!).
|
|
|
|
Now always check for a default unit, and evaluate the whole expression in this "unit space".
Not an ideal solution, but should handle most cases nicely
(we can't address all possible corner cases anyway).
Note default unit is searched in current string first (bigger unit of current system wins),
then in previous string.
Note this also replaces ',' by '+' in default separation between units,
helps solving issues with parenthesis (e.g. (1'1")*2.5 would fail in existing code)!
This would break if someone uses py ops with lower precedence than '+' (like bitwise
operations, and comparison), but these are not expected usecase here anyway.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D340
|
|
|
|
When converting text to value, units' "value" had only 6 digits of precision,
leading to annoying loss of precision esp. when mixing big and small units
(like e.g. miles and inches).
|
|
|
|
|
