Fix a regression that allowed to create several links between an
output socket and a multi input socket either by inserting
links or using the link swap feature.
This regression was caused by the link swapping feature
introduced in commit 89aae4ac82.
Pull Request: blender/blender#105631
Rename `struct ::UVPackIsland_Params` to
`class blender::geometry::UVPackIsland_Params`
Brings us closer to an "algorithm" style API.
No functional changes.
Multiple user actions performed quickly could be blocked by undo
compacting memory - if the background compacting task was not complete
when the next undo step was pushed.
Notes:
- This and recent improvements to BLI_array_Store gives over ~2x speedup
compared with 3.3x, over 10x compared with 3.4x.
A sub-surfaced cube with the modifier applied was used for testing
(~1.5 million polys), both randomized & non-randomized verts/edge/faces
were used to avoid the sub-surface memory layout biasing the results.
Tested transforming ~1/3rd of the mesh and inverting selection.
- Without compacting mesh-data in parallel, the optimizations to
BLI_array_store can give similar performance to 3.3x, however there
are still cases where performance isn't quite as good - so compact the
arrays in parallel to ensure performance is at least as good as 3.3x.
Resolves#105046.
The method of accumulating values to create a hash for each chunk has
been improved for ~16% better distribution of the resulting hashes.
Improve performance of array de-duplication, see: #105046.
Accumulating hashes with a byte/boolean array didn't include enough
information for a useful hash, creating hashes with many collisions.
This is the root cause of a performance regression since 3.3 where
mesh data (used for storing edit-mesh undo steps) was changed to store
selection in a boolean array, creating a bottleneck de-duplicating
chunks of that array for edit-mesh undo's custom-data de-duplication.
Resolve by increasing hash accumulation for arrays with smaller elements,
so each chunk of memory (a candidate for de-duplication) isn't as likely
to have hash collisions.
`char` (single byte) arrays now accumulate 22 values instead of 7, it's
taking more values into account was necessary as these are effectively
bits in the case of boolean arrays, 2-byte values accumulate 32 bytes,
4-byte elements accumulate 44 bytes, larger structs accumulate
`sizeof(type) * 7` bytes (as before).
Also ensure the accumulation read-ahead never exceeds the chunk size -
technically a fix although this would only happen when passing a small
`chunk_count` to BLI_array_store_create (in the range of 1-16) so this
didn't happen in practice.
Improve performance of array de-duplication, see: #105046.
Use uint32_t since it's sufficient for hashing, using an int64_t was
especially inefficient when allocating an int64_t for every boolean
(when compacting an array of booleans).
Improve performance of array de-duplication, see: #105046.
This is a fix for the previous commit d7c023eb25.
Before, every time the lambda was called, a copy of the BitVector was
made. This was very inefficient.
Now this has been fixed by passing the BitVector by reference (&) in
the lambda function.
In very specific cases, during intersection testing, `intersect` can
add polygons already checked as duplicates in the buffer that
corresponds to the rest of polygons that can form groups of duplicates.
As the buffer cannot have repeated indices, re-adding, even
temporarily, these duplicates can cause a buffer overflow.
While this may have some impact on performance, it's difficult to
predict these cases and thus add a buffer pad.
So the solution is to check if they are already duplicated.
Commit ea97bb1641 introducing the GHash mapping between objects and
their CollectionObject items in a Collection broke ID remapping of
collections's objects. Release builds would 'work', but debug builds
would assert in several ways when opening complex production files.
The root of the issue was a bad/missing handling of the 'duplicate case'
(several CollectionObjects pointing to a same Object).
While fixing the code was possible, it turned out to require disabling
to much safety checks. Further more, there was an opportunity to improve
efficiency of the related code in ID remapping (the pos-processing
checking for NULL and duplicates in collections objects lists).
This commit introduces a new 'dirty' tag for CollectionObject lists and
their ghash mappings.
This tag is set by the `foreach_id` callback when the `ob` pointer of a
CollectionObject is changed, and it is detected as (potentially)
breaking the consistency of that data.
This tag is then used by a new `BKE_collections_object_remove_invalids`
call, to only check and fix collections tagged as dirty, instead of all
the collections in the given Main. It replaces the previous
`BKE_collections_object_remove_nulls` and
`BKE_collections_object_remove_duplicates` functions.
The speed-up is about an order of magnitude for the clean-up code
itself, which gives 2-3 percent speed-up on resynching a complex
production file e.g.
This commit also includes some cleanups and re-organization of related
code.
Fix issues with the display of frame node labels, that made them
harder to read for people with low vision or on high dpi displays:
* Unclamp the size of text that is drawn in the frame node
so all sizes can be displayed consistently at all zoom levels
and independet of the UI scale.
* Account for the label when calculating the frame node's
bounds, so child nodes don't obscure the label.
Pull Request: blender/blender#104555
Don't expand view layer elements if element is previously used
This is similar as done for other display mode (eg. scene, library override)
Pass view_layer ID instead of scene as argument in `outliner_add_element`
Old Differential Revision: https://archive.blender.org/developer/D16661
Pull Request: blender/blender#104862
This patch enables edge panning for the operators where there was
a mismatch in behaviour between using the shortcut `G` and the
"Move" operator exposed via the menu and operator search.
Commit 19da434e9c introduced a `view2d_edge_pan` property which
was activated for the translate operators invoked when pressing G in
the default keymap.
The property is not enabled by default, to avoid it getting in the
way in some cases, so the "Move" operators exposed via the menus
didn't have edge panning. This lead to inconsistent behavior between
moving via the shortcut or via the menu.
Pull Request: blender/blender#104482
The use of wordexp(3) permits arbitrary code execution from manually-crafted
glTF files. See https://github.com/syoyo/tinygltf/issues/368 for more details.
In practice this shouldn't be an issue for Blender since the GlTF data isn't
manually crafted but from the OpenXR runtime (a bit like a driver). But
updating the library to include the fix is not a big deal anyway.
Note that the warning that required the local modification is no longer present upstream since
0bfcb4f49e
Pull Request: blender/blender#105536
Workaround for a crash when `addComputePipelineFunctionsWithDescriptor` is called *after* `newComputePipelineStateWithDescriptor` with linked functions (i.e. with MetalRT enabled). Ideally we would like to call `newComputePipelineStateWithDescriptor` (async) first so we can bail out if needed, but we can stop the crash by flipping the order when there are linked functions. However when addComputePipelineFunctionsWithDescriptor is called first it will block while it builds the pipeline, offering no way of bailing out.
Note that this only has an impact when the "MetalRT (Experimental)" option is checked.
Pull Request: blender/blender#105629
The reasoning is that the detail namespace is not to be used
outside the module itself. But one might want to use different
number types with these templates.
The `Base` suffix was chosen in order to be consistent with `MatBase`
and `Vector` naming convention.
Refactor the following functions and cover with tests
* `BKE_fcurve_calc_bounds` - used to get the `rctf` bounding box of an fcurve
* `BKE_fcurve_calc_range` - used to get only the x-range, potentially faster when not needing y extents
`get_fcurve_end_keyframes` has been replaced with `get_bounding_bezt_indices` - dealing with indices allows to iterate over that range later
### BKE_fcurve_calc_bounds
* pass in an `rctf` instead of float pointers
* extract logic to get bounds into separate functions
### BKE_fcurve_calc_range
* removed the parameter `do_min_length` it was always false, and this function shouldn't concern itself with clamping.
Calling code can do that if the return bool is false
* use function to get x bounds separated from `BKE_fcurve_calc_bounds`
Pull Request: blender/blender#105177
Archlinux faced an issue with AoT compilation: https://bugs.archlinux.org/task/77554
These were due to compiler flag strings handling going wrong when cmake
calls the custom command. It ended up moving quotes around, leading flags to
get passed to the main compiler instead of the graphics compiler and trigger
the following error: "Unrecognized build options: -ze-opt-regular-grf-kernel".
Pull Request: blender/blender#105615
