Pinned islands with "Lock Position" were not interacting correctly
when the packing destination was not at the origin.
This could happen with "Pack To : Original Bounding Box", and also
when packing to a UDIM other than 1001.
In several nodes, and sculpt brushes, use the proper `IndexMask` type
instead of a span of ranges to encode a selection. This allows deleting
the duplicate data copying utilities using the second format.
Goals of this refactor:
* Reduce memory consumption of `IndexMask`. The old `IndexMask` uses an
`int64_t` for each index which is more than necessary in pretty much all
practical cases currently. Using `int32_t` might still become limiting
in the future in case we use this to index e.g. byte buffers larger than
a few gigabytes. We also don't want to template `IndexMask`, because
that would cause a split in the "ecosystem", or everything would have to
be implemented twice or templated.
* Allow for more multi-threading. The old `IndexMask` contains a single
array. This is generally good but has the problem that it is hard to fill
from multiple-threads when the final size is not known from the beginning.
This is commonly the case when e.g. converting an array of bool to an
index mask. Currently, this kind of code only runs on a single thread.
* Allow for efficient set operations like join, intersect and difference.
It should be possible to multi-thread those operations.
* It should be possible to iterate over an `IndexMask` very efficiently.
The most important part of that is to avoid all memory access when iterating
over continuous ranges. For some core nodes (e.g. math nodes), we generate
optimized code for the cases of irregular index masks and simple index ranges.
To achieve these goals, a few compromises had to made:
* Slicing of the mask (at specific indices) and random element access is
`O(log #indices)` now, but with a low constant factor. It should be possible
to split a mask into n approximately equally sized parts in `O(n)` though,
making the time per split `O(1)`.
* Using range-based for loops does not work well when iterating over a nested
data structure like the new `IndexMask`. Therefor, `foreach_*` functions with
callbacks have to be used. To avoid extra code complexity at the call site,
the `foreach_*` methods support multi-threading out of the box.
The new data structure splits an `IndexMask` into an arbitrary number of ordered
`IndexMaskSegment`. Each segment can contain at most `2^14 = 16384` indices. The
indices within a segment are stored as `int16_t`. Each segment has an additional
`int64_t` offset which allows storing arbitrary `int64_t` indices. This approach
has the main benefits that segments can be processed/constructed individually on
multiple threads without a serial bottleneck. Also it reduces the memory
requirements significantly.
For more details see comments in `BLI_index_mask.hh`.
I did a few tests to verify that the data structure generally improves
performance and does not cause regressions:
* Our field evaluation benchmarks take about as much as before. This is to be
expected because we already made sure that e.g. add node evaluation is
vectorized. The important thing here is to check that changes to the way we
iterate over the indices still allows for auto-vectorization.
* Memory usage by a mask is about 1/4 of what it was before in the average case.
That's mainly caused by the switch from `int64_t` to `int16_t` for indices.
In the worst case, the memory requirements can be larger when there are many
indices that are very far away. However, when they are far away from each other,
that indicates that there aren't many indices in total. In common cases, memory
usage can be way lower than 1/4 of before, because sub-ranges use static memory.
* For some more specific numbers I benchmarked `IndexMask::from_bools` in
`index_mask_from_selection` on 10.000.000 elements at various probabilities for
`true` at every index:
```
Probability Old New
0 4.6 ms 0.8 ms
0.001 5.1 ms 1.3 ms
0.2 8.4 ms 1.8 ms
0.5 15.3 ms 3.0 ms
0.8 20.1 ms 3.0 ms
0.999 25.1 ms 1.7 ms
1 13.5 ms 1.1 ms
```
Pull Request: https://projects.blender.org/blender/blender/pulls/104629
Combine the newer less efficient C++ implementations and the older
less convenient C functions. The maps now contain one large array of
indices, split into groups by a separate array of offset indices.
Though performance of creating the maps is relatively unchanged, the
new implementation uses 4 bytes less per source element than the C
maps, and 20 bytes less than the newer C++ functions (which also
had more overhead with larger N-gons). The usage syntax is simpler
than the C functions as well.
The reduced memory usage is helpful for when these maps are cached
in the near future. It will also allow sharing the offsets between
maps for different domains like vertex to corner and vertex to face.
A simple `GroupedSpan` class is introduced to make accessing the
topology maps much simpler. It combines offset indices and a separate
span, splitting it into chunks in an efficient way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107861
The rotation options are now:
* None
* Axis-Aligned (Blender 3.3 default)
- Rotate to a minimal rectangle, either vertical or horizontal.
* Cardinal (new)
- Only 90 degree rotations are allowed.
* Any
- Blender 3.6 default.
During packing, some combinations of `Fraction` margin method, and
various locking options, interact with situations where all or none
of the islands are pinned.
Previously, the settings were queried to choose the best packing method.
Now, the islands themselves are queried if they can translate or scale,
and the packing method is chosen based on the input, rather than the
parameters.
Fixes unreported crash with "Locked Position" when all islands are pinned.
Reported as #108037 "3. In some case locked position is not respected"
When rotation is enabled and doing a scale line-search (locked islands
or "fraction" margin method), if the `rotate_inside_square` would
result in a a tighter packing, the wrong scale value was being used,
resulting in UVs outside of the unit square.
Reported as #108037 "1. Use locked scale on after scaling UV..."
If an island overlaps a pinned island, and that pinned island has
locked scale, then the pinning information must be copied to the
first island so it can be scaled correctly.
Reported in #108037 as "2. Use with Merge Overlapped"
Store bevel weights in two new named float attributes:
- `bevel_weight_vert`
- `bevel_weight_edge`
These attributes are naming conventions. Blender doesn't enforce
their data type or domain at all, but some editing features and
modifiers use the hard-coded name. Eventually those tools should
become more generic, but this is a simple change to allow more
flexibility in the meantime.
The largest user-visible changes are that the attributes populate the
attribute list, and are propagated by geometry nodes. The method of
removing this data is now the attribute list as well.
This is a breaking change. Forward compatibility is not preserved, and
the vertex and edge `bevel_weight` properties are removed. Python API
users are expected to use the attribute API to get and set the values.
Fixes#106949
Pull Request: https://projects.blender.org/blender/blender/pulls/108023
Minor corrections including:
* Fast packer wasn't treating locked islands correctly.
* Pointer aliasing.
* Fix and some assumptions that might not be always true.
* Improve variable names.
* Improved comments.
This makes the Blender binary 350 KB smaller. The largest change comes
from using `FunctionRef` instead of a template when gathering indices to
mix in the extrude node (which has no performance cost). The rest of the
change comes from consolidating uses of code generation for all
attribute types. This brings us a bit further in the direction of
unifying attribute propagation.
Pull Request: https://projects.blender.org/blender/blender/pulls/107823
Adds a generic `is_larger` and `get_aspect_scaled_extent` function to
simplify packing logic.
Migrate several packing functions so that they only improve a layout,
and early-exit packing if a better layout already exists.
Fix a `rotate_inside_square` logic error during xatlas packing.
Use the offset indices pattern to avoid keeping separate arrays for the
offset of a vertex's neighbors and the number of neighbors. This gave
a 9% speedup for the conversion, from 42.9 ms to 39.3 ms.
`sinf(float_angle)` is sometimes producing different results on
x86_64 cpus and apple silicon cpus. Convert to double precision
to increase accuracy and consistency.
Partial fix for #104513. More to come.
Introduces "Optimal" packing, where the layout is a theoretical
best possible for a given input.
e.g. https://erich-friedman.github.io/packing/squinsqu
Also calls multiple packing algorithms, and chooses the best one.
The fact that blenlib doesn't know about the set of attribute types is
actually an important detail right now that can influence how things
are designed. Longer term it would be good to consolidate many of
these attribute propagation algorithms anyway.
In some cases the node didn't reproduce the same results given the
same input. Based on the test results (just 2 very detailed cubes
and a transformation), it doesn't seem to affect performance that
much. Credit to @MMMM who pointed out this option.
Pull Request: https://projects.blender.org/blender/blender/pulls/107312
* Perform rotate_inside_square earler in the pipeline. (improved layout)
* #rotate_inside_square with AABB margin if there is only one island.
* Conservative bounds when using xatlas on non-D4 transforms.
After primary packing is completed, perform a deep earch for any
rotation of the entire layout which improves efficiency even further.
This can sometime provides *optimal* packing results. e.g. When packing
a single island, the layout will now touch all 4 sides of the unit square.
When UV Packing with the `fraction` margin method, if the UVs
overflowed the unit square, the UVs could sometimes overlap.
(island_index was incorrect.)
When `scale_to_fit` is enabled, the existing behavior is used,
UVs will be scaled to fill the unit square.
If disabled, UVs will not be rescaled. They will be packed to the
bottom-left corner, possibly overflowing the unit square, or not
filling space.
It arguably reads easier if simple operations like reading from indices
of an array don't each get their own line. Also the same corner
attribute sampling was repeated in a few places. And add a new
function to sample normals from the corner domain, and use
lower level arguments to the lower level functions (i.e. not just
a mesh pointer, but the necessary data arrays).
