Changes:
- Renamed Split Viewer Node to Split Node
- Split Node is now under `Utilities` (similar to Switch node)
- Versioning: split viewer from 4.0 and before is replaced with the new split node connected to a new viewer node.
Pull Request: https://projects.blender.org/blender/blender/pulls/114245
Instead of allocating a separate bitmap per grid for the hide status, store
all the bits in a recently added C++ data structure that stores all bits in one
contiguous memory chunk. When nothing is hidden, nothing is allocated
(that saves 32 MB for a 16 million vertex multires sculpt). Intuitively it
could have better performance because of the cache benefits of
contiguous memory, but this is hard to measure. It also has a nicer
API than `BLI_bitmap`.
I discussed this with Sergey in person recently. Most of the changes are
just straightforward refactors. The part that isn't is a change to the "show/hide"
operator to structure it similarly to the mesh handling in 4e66769ec0.
Pull Request: https://projects.blender.org/blender/blender/pulls/115687
This merge does not rename any ID. In case a conflict happens (an ID of
the same name and library already exists in destination Main), its
counterpart in source Main is not moved, and its usages by other
moved-from-source IDs are remapped accordingly.
Libraries are also properly de-duplicated, and remapped as necessary.
Source Main is always freed by this function, since it is either empty,
or contains left-over IDs very likely to have invalid relationships
after the merge.
NOTE: This commit also enables `main_test.cc` unittests, which was
comitted by mistake in fe3cb11ae4, sorry about that.
Pull Request: https://projects.blender.org/blender/blender/pulls/115671
Usually Library pointers should not be affected by remapping, but this
can be needed in some cases.
WARNING: Use with caution, this is potentially a dangerous operation for
Main data integrity/validity.
The constness of the `ImplicitSharingPtr` does not imply the constness of the
referenced data, because that is determined by the user count. Therefore,
`ImplicitSharingPtr` should never give a non-const pointer to the underlying data.
Instead, one always has to check the user count, before one can do a `const_cast`.
Pull Request: https://projects.blender.org/blender/blender/pulls/115652
Avoid reusing the custom data type enum with additional values. Instead
use std::variant and type names to properly distinguish between custom
and generic attribute requests. Use a Vector to hold the requests.
Also attempt to simplify the string key building process for requests
and groups of requests in batches. Previously for every PBVH node it
would rebuild the key 3 times, now it only does it once. It's hard to
measure, but that process did show up in profiles, so performance is
probably slightly improved when many nodes are handled at once.
Pointers to hide status layers and custom data are removed,
since they can be accessed from the mesh as necessary.
Usage of other arrays has been reduced, so the pointers
can eventually be removed.
The reasoning is the same as some other commits in this area:
the goal is less duplication of state, and a more focused design
of the responsibilities of the PBVH class.
Some of the changes are fairly noisy, since we need to add
arguments to functions in a few places. On the nicer side of
things, some functions for syncing the state can be removed.
Not retrieving hide layers with write access also has performance
implications in some cases, since it means the original arrays can
be reused without a copy when they're shared.
This improves the early out in the mesh case so that it isn't
repeated for every node. Also simplifies using more local
variables that are specific to a certain PBVH type (in this
case, switching to the C++ attribute API and retrieving the
vertex visibility status that way).
- Pass Span by value. It is a small struct, and passed by reference
it acts as a pointer to a pointer.
- Remove unnecessary `= {}`. Vector has a default constructor.
- Use initializer list Span constructor to avoid temporary array.
Pull Request: https://projects.blender.org/blender/blender/pulls/115635
These are just duplicates of the pointers in `SubdivCCG`, which are
already quickly accessible. Keeping track of the state is too complex
and bloats the responsibilities of the PBVH too much.
Our `EnumerableThreadSpecific` wrapper doesn't accept an
example argument, only an initialization function. And some
removed variables were still used in asserts.
Caused by 383a145a19
Since above commit, normals were in a SharedCache, they need to be tagged dirty
for recalculation.
Instead of tagging the normals caches dirty explicitly, simply use
`BKE_mesh_tag_positions_changed` [which includes all this and also tags
positions dirty - which sounds also needed for updating other things]
Pull Request: https://projects.blender.org/blender/blender/pulls/115580
These updates are used to recalculate normals and average values between
grid boundaries during multires sculpting. In main the affected faces
are passed as an array of pointers. Using an `IndexMask` instead reduces
memory usage by 4x per affected face (8 byte pointer to 2 byte integer),
simplifies iteration and threading, and can also improve performance.
Finding which faces are affected is now multithreaded, with its runtime
changing from 0.63 ms to 0.12 ms in a simple test sculpting on a portion
of a 1 million face grid.
Also switch to VectorSet instead of GHash for finding affected adjacent
elements. That's a friendlier data structure that probably has better
performance as well.
The new grid socket (#115270) will make these nodes obsolete and
provide more elegant ways of implementing the features. Removing
these nodes now to clean up and make future changes simpler.
Pull Request: https://projects.blender.org/blender/blender/pulls/115567
Because reading memfile undo steps doesn't send the mesh through the
versioning code that converts legacy layers back to the new generic
format, we can't write the old format in undo steps. This same check
existed during the mesh struct of array refactor.
