This utility was already duplicated in two places and planned to be used
more. While we should usually avoid creating arrays the size of the
indexed array (rather than the size of the mask), sometimes it does seem
to be the best option, and we're helped by the fact that most memory
stays unintialized for a small mask (allocating but not writing to memory
pages at all generally isn't too expensive).
Pull Request: https://projects.blender.org/blender/blender/pulls/115491
The ImplicitSharingPtr has an implicit constructor for raw pointers.
This has unintended effects when comparing an ImplicitSharingPtr to a
raw pointer: The raw pointer is implicitly converted to the shared
pointer (without change in refcount) and when going out of scope will
decrement user count, eventually freeing the data.
Conversion from raw pointer to shared pointer should not happen
implicitly. The constructor is made explicit now. This requires a little
more boilerplate when constructing a sharing pointer. A special
constructor for the nullptr is added so comparison with nullptr can
still happen without writing out a constructor.
Pull Request: https://projects.blender.org/blender/blender/pulls/115476
For improving performance in the triangulate node (#112264), it's
helpful to know whether the mesh has edges or faces that overlap
each other. If that is known to be false, the node can skip edge de-
duplication.This might apply to the future "Replace Faces" node too.
This information is stored as a flag on the mesh and set in various
places that create "clean" new meshes. It isn't calculated lazily unlike
other other areas, because the point is to improve performance, and
the calculation probably isn't faster than the duplication check it's
meant to replace.
Pull Request: https://projects.blender.org/blender/blender/pulls/113205
Restore lost performance from removing `reserve` in ff4d5b6f04
in a better way. First build offsets so we know where in the result the
source data should go, then copy the data in parallel.
Joining geometries containing 1 million instances each took 194 ms
before the change and only 15.6 ms afterwards.
Pull Request: https://projects.blender.org/blender/blender/pulls/113886
This was the last use of `CustomDataAttributes`. It's not very useful
nowadays because we have a lower level (`CustomData`) and higher level
(`AttributeAccessor`) API.
As part of this I removed the ability to `reserve` instances which was
useful when adding instances one by one. Generally, such code should
eventually be rewritten to handle more instances at once, instead of
handling them one by one. This will lead to better performance and
is more in line with how other geometry types (like mesh) are handled.
This also adds the ability to move and assign `Instances` just like we can
move and assign `CurvesGeometry`.
`CustomDataAttributes` does not serve much of a purpose nowadays,
since we usually use either the lower level `CustomData` or the higher
level `AttributeAccessor` interface.
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.
Curve type conversion can cause changing of some curves size.
Also, changing of curve type can cause deletion of unnecessary
built-in attributes and creating new ones. All of this make sense
only for converted curves. Others, unselected, should simply make
copy all old attributes, both built-in and not. This fix simply replaces
the last copy from incorrect only non-built-in, to a correct one,
for all attributes.
Pull Request: https://projects.blender.org/blender/blender/pulls/110683
`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.
See cc7da09c1b.
Splitting edges only potentially affects the order of edges and
vertices. Face corner vertex and edge indices are affected, but their
order isn't affected, and faces aren't affected at all. This didn't
cause problems, but correcting it shows users they can rely on
these consistencies after this operation.
Sometimes .blend files have compatibility issues between Blender versions,
because .blend files depended on the specific order of geometry elements
generated by some nodes/modifiers (#112746, #113018). While we make
guarantees about the order in some places, that is relatively rare, because it
makes future improvements much harder. The functionality in this patch
makes it easier for users to notice when they depend on things that are not
expected to be stable between Blender builds.
This is achieved by adding a new global flag which indicates whether some
algorithms should randomize their output. The functionality can be toggled
on or off by searching for `Set Geometry Randomization`. If there are no
differences (or acceptable minor ones) when the flag is on or off, one can
be reasonably sure that one does not on unspecified behavior (can't be 100%
sure though, because randomization might be missing in some places). If
there are big differences, one should consider fixing the file before it comes
to an actual breakage in the next Blender version.
Currently, the setting is only available when `Developer Extras` is turned on,
because the setting is in no menu.
With this patch, if we get bug reports with compatibility issues caused by
depending on indices, one of the following three cases should always apply:
* We actually accidentally broke something, which requires a fix commit.
* Turning on geometry randomization shows that the .blend file depends on
things it shouldn't depend on. In this case the user has to fix the file.
* We are missing geometry randomization somewhere, which requires a fix
commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113030
MSVC 17.7 generates bad code in some lambda's, this has been reported
upstream [1], and a workaround has been suggested by MS in the form of
turning the inliner off. In consultation with the geo nodes people this
was deemed a passable solution, there was only a single call to this
method so performance wasn't a concern, so no special care had to be
taken to single out just the problematic MSVC versions.
If this bug pops up in other parts of our code where performance IS a
concern a more delicate approach may be required.
[1] https://developercommunity.visualstudio.com/t/10448291
Pull Request: https://projects.blender.org/blender/blender/pulls/112616
The weld modifier was experiencing crashes due to the `switch_to`
variable occasionally pointing to a collapsed corner.
The encumbrance of the code implementation utilizing `switch_to` was
proving to be problematic as it was escalating the complexity of
maintenance.
To resolve the issue, a code rewrite was conducted.
The new implementation uses a `loop_next` in place of `switch_to` for
skipping corners.
This modification streamlined the code and improved its stability.
However, this solution does come with minor drawbacks. There is a small
increase in memory consumption and the corner group detection process
is now slightly more computational intensive.
Also the test files need to be updated.
When multiple packing methods results in effectively the same bounds,
prefer the packer that uses the smallest area. When all islands can
easily fit this is usually the box packer instead of alpaca. The zigzag
method of the latter has a tendendcy to take up more area and rotate
islands.
Fix#110724: smart UV project unnecessarily rotates islands
Pull Request: https://projects.blender.org/blender/blender/pulls/112295
This has a tendency to place islands diagonally in the image which is
not usually wanted, even if it's maximimizing the number of pixels for
the island.
Fix#109906: UV unwrap packs island diagonally instead of straight
Pull Request: https://projects.blender.org/blender/blender/pulls/112295
This makes the code reusable in a few more places,
particularly by tests for a new boolean implementation
also defined in the geometry module.
It also makes the way some primitives are reused among
different nodes a bit clearer.
Pull Request: https://projects.blender.org/blender/blender/pulls/112255
Regression [0] which merged index assignment into an earlier loop.
This caused the indices to be overwritten by p_chart_abf_solve
causing unwrap to fail.
[0]: 8ace65e3c6
The hash tables and vector blenlib headers were pulling many more
headers than they actually need, including the C base math header,
our C string API header, and the StringRef header. All of this
potentially slows down compilation and polutes autocomplete
with unrelated information.
Also remove the `ListBase` constructor for `Vector`. It wasn't used
much, and making it easy to use `ListBase` isn't worth it for the
same reasons mentioned above.
It turns out a lot of files depended on indirect includes of
`BLI_string.h` and `BLI_listbase.h`, so those are fixed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111801
