Replacing the "cyclic offsets" cache from cfb8696a73.
That was more information than was necessary in the end.
This is implemented by de-duplicating the existing "contains"
function that's implemented twice for boolean virtual arrays.
Pull Request: https://projects.blender.org/blender/blender/pulls/144761
Typically, we use this function to determine whether or not a subset of
data that has been collected with `gather` needs to be then persisted
into a larger array with `scatter`. As such, it makes sense to assert on
equality of the indices and smaller array size.
Pull Request: https://projects.blender.org/blender/blender/pulls/140752
"Origin to Geometry" was also affected
With very large meshes (report was about this failing for imported
terrain data), we lack precision in `BKE_mesh_center_median`.
First intuition was to just use doubles, but based on the work done
in !132759 to get a more numerically stable way to compute a mean,
we can use that instead.
So this PR moves `compute_sum` into `blender::array_utils`
and re-uses that for `BKE_mesh_center_median`
Pull Request: https://projects.blender.org/blender/blender/pulls/138813
This PR inverts the return values of `indexed_data_equal` to make the
function return as one would expect (i.e. if everything is equal then it
returns true, if any are not equal it returns false)
Pull Request: https://projects.blender.org/blender/blender/pulls/121056
This makes the edit mode drawing for the new curves data more similar
to the old edit mode. Specifically, it draws the evaluated curves now instead
of just a poly curve. Furthermore, it now draws bezier handles as well as
a separate control curve for nurbs curves.
Pull Request: https://projects.blender.org/blender/blender/pulls/119053
Unless you're very familiar with `IndexRange`, it's often hard to know what
e.g. `IndexRange(10, 15)` means. Without more context, one could think
that it means `10-14`, `10-15` or `10-24`. This patch adds named constructors
to `IndexRange` to make the behavior more obvious when writing and when
reading the code. With those one can use `IndexRange::from_begin_end(10, 15)`,
`IndexRange::from_begin_end_inclusive(10, 15)` or `IndexRange::from_begin_size(10, 15)`
respectively. While being a bit more verbose, the explicitness makes code easier to
understand and also allows abstracting away some common index computations.
The old unnamed constructor that takes a begin and size is not removed by this patch,
as that would make the patch significantly bigger. I think it's reasonable to generally
use the named constructors going forward and to change the existing usages of the
old constructor over time.
Pull Request: https://projects.blender.org/blender/blender/pulls/118606
This PR makes it so that locked materials as well as hidden materials will not have their edit points and edit lines visible.
Note: Previously in grease pencil, strokes with hidden materials would still display the edit lines. This behavior is now fixed in GPv3.
Pull Request: https://projects.blender.org/blender/blender/pulls/115740
This will be useful for other types in the future (similar abstractions
for editing face sets), and it makes more semantic sense as a templated
utility function.
Add a function that copies selected values to groups of values in the
result array. Add a runtime-typed version and a version for affecting
all attributes. Also make the "gather_group_to_group" follow the
same pattern.
Simply sets the cyclical property selected strokes. Note this does not add extra geometry like the legacy operator.
Note: also adds a key bind 'alt c' to toggle, same as for curves.
Resolves#113671
Pull Request: https://projects.blender.org/blender/blender/pulls/111904
Avoid the need to iterate over every curve, and only iterate over the
cyclic attribute if it exists. This removes the check that avoided
creating cyclic segments for curves with only two points. If that
was necessary, some of the complexity would return, but the
new `array_utils` function wouldn't be necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/113814
Use the typical combination of an "array utils" function used by an
attribute interpolation function. This helps moves us towards having
a more centralized implementaiton of attribute propagation that can
be changed and optimized more easily.
`iota` is name that has no meaning, it's not an acronym or initialism.
It's usually very cryptic when I come across it. Replacing it with a
specialized function makes the code more readible.
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
This utility counts the number of occurrences of each index in an array.
This is used for building mesh topology maps offsets, or for counting
the number of connected elements. Some users are geometry nodes,
the subdivision draw cache, and mesh to curve conversion.
See #109628
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
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
- Implement mesh creation in GeometrySet agnostic way, with less context
- Remove useless comments
- Use a field to clamp crease values instead of clamping when copying
- Small variable name tweaks
- Use `BKE_subdiv_new_from_mesh` instead of "update"
- Remove crease layers before writing, avoiding potential copy
The position attribute has special meaning for point clouds, and
meshes and curves have access methods for the attribute as well.
This saves boilerplate and gives more consistency between types.
Since UVs are now stored as 2D vectors in meshes, they can be copied
directly to the vertex buffers. Somewhat surprisingly, multithreading
the copying into the vertex buffer provides a good speedup-- on a CPU
with many cores at least.
Here is a test uploading two UV maps created in geometry
nodes with a 1 million quad mesh, with a Ryzen 7950x:
| | Before | After | Speedup |
| ------- | ------- | ------ | ------- |
| Average | 24.3 ms | 7.5 ms | 3.2x |
| Min | 17.6 ms | 7.0 ms | 2.5x |
I added the copying utilities to the array utils header, since the
need for them has come up in a few different places already, and the
existing function with a selection argument didn't make sense here.
Pull Request: https://projects.blender.org/blender/blender/pulls/105793
Use the same `".selection"` attribute for both curve and point domains,
instead of a different name for each. The attribute can now have
either boolean or float type. Some tools create boolean selections.
Other tools create float selections. Some tools "upgrade" the attribute
from boolean to float.
Edit mode tools that create selections from scratch can create boolean
selections, but edit mode should generally be able to handle both
selection types. Sculpt mode should be able to read boolean selections,
but can also and write float values between zero and one.
Theoretically we could just always use floats to store selections,
but the type-agnosticism doesn't cost too much complexity given the
existing APIs for dealing with it, and being able to use booleans is
clearer in edit mode, and may allow future optimizations like more
efficient ways to store boolean attributes.
The attribute API is usually used directly for accessing the selection
attribute. We rely on implicit type conversion and domain interpolation
to simplify the rest of the code.
Differential Revision: https://developer.blender.org/D16057
Attribute copying often uses identical logic for copying selected
elements or copying with an index map. Instead of reimplementing
this in each file, use the common implementation in the array_utils
namespace. This makes the commonality more obvious, gives improved
performance (this implementation is multithreaded), reduces binary
size (I observed a 173KB reduction), and probably reduces compile time.
Add new functions to `array_utils` namespace called `gather(..)`.
Versions of `GVArray::materialize_compressed_to_uninitialized(..)` with
threading have been reimplemented locally in multiple geometry node
contexts. The purpose of this patch is therefore to:
* Assemble these implementations in a single file.
* Provide a naming convention that is easier to recognize.
Differential Revision: https://developer.blender.org/D15786
The trim functionality is implemented in the geometry module, and
generalized a bit to be potentially useful for bisecting in the future.
The implementation is based on a helper type called `IndexRangeCyclic`
which allows iteration over all control points between two points on a
curve.
Catmull Rom curves are now supported-- trimmed without resampling first.
However, maintaining the exact shape is not possible. NURBS splines are
still converted to polylines using the evaluated curve concept.
Performance is equivalent or faster then a 3.1 build with regards to
node timings. Compared to 3.3 and 3.2, it's easy to observe test cases
where the node is at least 3 or 4 times faster.
Differential Revision: https://developer.blender.org/D14481
