Hex color values are now always in sRGB space, as would be expected by
most other applications. Previously they were in display space and using
the view transform.
In 2d655d3 the color picker was changed to use display space HSV values.
This works ok for a simple sRGB EOTF, but fails with view transforms like
Filmic where display space V 1.0 maps to RGB 16.292.
Instead we now use the color_picking role from the OCIO config when
converting from RGB to HSV in the color picker. This role is set to sRGB
in the default OCIO config.
This color space fits the following requirements:
* It is approximately perceptually linear, so that the HSV numbers and
the HSV cube/circle have an intuitive distribution.
* It has the same gamut as the scene linear color space.
* Color picking values 0..1 map to scene linear values in the 0..1 range,
so that picked albedo values are energy conserving.
In production files that use a lot of linking I measured loading speedups between 5% and 18%. In files that use less linking the speedup might not be noticeable at all, but it should not be slower.
Reviewer: brecht
Differential Revision: https://developer.blender.org/D4038
The new data structure uses open addressing instead of chaining to resolve collisions in the hash table.
This new structure was never slower than the old implementation in my tests. Code that first inserts all edges and then iterates through all edges (e.g. to remove duplicates) benefits the most, because the `EdgeHashIterator` becomes a simple for loop over a continuous array.
Reviewer: campbellbarton
Differential Revision: D4050
Mostly rewrite logic which now matches (de)select picking,
share between both operators.
- Support all selection operations (eSelectOp), fixes T59255.
- Add function that selects using 'BONESEL_*' flags & eSelectOp.
This avoids lasso & box select having to handle selection flushing.
- Fix strange behavior with lasso where selecting a bone in a chain
would only select the tip (from 2.7x).
There are some minor differences in center calculation but I don't think
they're important, if so we can update the code.
- Edit-bone uses head (instead of the middle when both are selected).
- Edit-bone flag for restricting components uses the selection instead
of the active bone.
It should be possible to use this when the active element is unselected, but
there still needs to be something else selected. Otherwise it is not possible
to deselect all as a way to get the gizmo out of the way.