`BLI_space_transform_from_matrices()` defines a 'global-invariant' transform
(same point in global space, two different coordinates in local and target spaces).
New `BLI_space_transform_global_from_matrices()` is kind of opposite, it defines
a 'local-invariant' transform (two different points in global space, same coordinates in local and target spaces).
Useful to 'match' meshes.
This commit:
* Adds a 'compare_ff' function for absolute 'almost equal' comparison of floats.
* Makes 'compare_vxvx' functions use that new 'compare_ff' one.
* Adds a 'compare_ff_relative' function for secured ulp-based relative comparison of floats.
* Adds matching 'compare_vxvx_relative' functions.
* Adds some basic tests for compare_ff_relative.
See https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
Note that we could replace our python/mathutils' EXPP_FloatsAreEqual() by BLI's compare_ff_relative
(using a very small absolute max_diff), but these do not have exact same behavior...
Left a comment there for now, we can do it later if/when we are sure it won't break anything!
Simply backport small part of work from asset-experiments here (using double and
adding tera-bytes unit), looks like off_t is not always 64bits even on a 64bit OS...
Number of system threads is quite difficult to change without need of blender
restart, so we can cache result of the systcalls (which are not really cheap)
in order to be able to call BLI_system_thread_count() without worrying of
performance issues in that function.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1342
Avoid data type re-declaration, it's not really working on current FreeBSD's 9
system and CLang-3.0 from OSX.
This is not a good idea to do such sort of copy-paste anyway.
If someone knows better way of dealing with this please go ahead and correct
the code :)
For areas that require append, store the last node,
Previous behavior would too easily hide poorly performing code.
Also avoid (prepend, reverse) where possible.
Adds support for selecting/deselecting files in File Browser using the
arrow keys. All directions (up, down, left, right) are possible.
When to Select, When to Deselect?
Standard behaviour is selecting, however if we move into a block of
already selected files (meaning 2+ files are selected) we start
deselecting
Possible Selection Methods
Simple selection (arrow-key): All other files are deselected
Expand selection (Shift+arrow key): Add to/remove from existing
selection
ill-Expand selection (Ctrl+Shift+arrow key): Add to/remove from existing
selection and fill everything in-between
From which file do we start navigating?
From each available selection method (Mouse-, Walk-, All-, Border
Select), we use the last selected file. If there's no selection at all
we use the first (down/right arrow) or last (up/left arrow) file.
(Ideally, the view would automatically be set to the new selection, but
this behaviour overlaps with an other patch I've been working on, so
prefer to do that separately)
(Also tweaks color for highlighted file for better feedback)
D1297, Review done by @campbellbarton, thx a lot :)
For a long time this function was only intended to be used from the main thread,
but since out implementation of parallel range (which is currently only used by
mesh deform modifier) we might want to switch to threaded alloc from object
update thread.
Now we're using spinlock around the check, which makes the code safe to be used
from all over the place.
We might consider using a bit of atomics operations magic there, but it's not so
much important for now, this code is not used in the performance critical code
path.
