This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
The `groups_map` array (which indicates the group an element belongs
to) is only intended to reduce loops when creating groups, speeding up
that part of the code.
But on the downside, it requires more memory usage, and adds one more
step to access groups (`groups_offs[groups_map[i]]` instead of just
`groups_offs[i]`).
So removing that array decreases memory usage and speeds up access in
another part of the code.
The profile showed a +6% advantage when the Weld modifier affects large
portions of the mesh.
But it also showed a loss of around -0.6% in performance for cases
where the Weld modifier affects small parts of the mesh.
The biggest benefit is to save memory and speed up some cases.
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
- Deduplicate code;
- Support no customdata interpolation for edges;
- Reduce number of required elements in context arrays.
With 74772c6920, the merge by distance code for meshes now supports
optional interpolation of custom data for vertices.
As this can be advantageous for performance and memory, it seems
convenient to support the same for edges (and in the future polygons
and corners).
So this commit reworks the code that finds the edge groups to match the
same used for vertices and thus deduplicating and simplifying the code.
Conveniently the `edge_ctx_map` array is no longer needed and can be
removed to save memory.
However it was necessary to create another array (which is usually
smaller) called `double_edges` (to match `double_verts`).
---
**Results:**
The profiling result depends on some factors such as:
- interpolate or not interpolate customdata;
- affect a large or small portion of the mesh;
The best case is when the customdata **is not** interpolated and the operation affects **large** portions of the mesh:
| Before: | After: | Factor: |
| ---------- | ---------- | ------- |
| 1256.61 ms | 1073.218 ms| -14.44% |
The worst case is when the customdata **is not** interpolated and the operation affects **small** portions of the mesh:
| Before: | After: | Factor: |
| --------- | --------- | ------- |
| 1077.50 ms| 1086.7 ms| +0.85% |
Pull Request: https://projects.blender.org/blender/blender/pulls/109836
The merging behavior of the Array, Mirror, Screw modifiers has changed
since 4369627e71.
Before, only the customdata of the destination vertex was kept. Source
vertices were completely removed.
With 4369627e71, all vertices in the merge group (whether source or
destination) now have their customdata interpolated.
But this can cause problems for example with the root vertex customdata
of the skin modifier, where if only one of the vertices of the group of
vertices has this flag, the resulting one will also have it.
This commit restores the behavior for the vertices customdata and does
not interpolate it if `do_mix_vert_data` is false.
Pull Request: https://projects.blender.org/blender/blender/pulls/109627
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
When the vertex indices are already ordered like curve points, the
attribute arrays can be shared with the result mesh. This reduces
memory and saves time copying the data. The improvement is
larger when the mesh contains more point domain attributes.
The `vert_dest_map` array, which contains a map indicating the index of
destination vertices, was being copied to another array (`WeldVert`)
unnecessarily.
By directly using the `vert_dest_map` array, we achieved a performance
improvement.
The average execution time of different operations was reduced from
267.4ms to 261.3ms, resulting in a 2.3% improvement in overall
performance.
Also see #103343.
There was one unusual complication due to `openvdb` here. The `BKE_volume.h`
header included `openvdb` but that would not link correctly in rna code. I'm not entirely
sure why any of the openvdb code is actually instantiated, may be an issue in the
`openvdb` headers. The solution is to create a new header that gives access to the
underlying `openvdb` data structure for a `Volume` geometry. This header can't be
included in rna for now, until the linking issues are resolved.
Pull Request: https://projects.blender.org/blender/blender/pulls/109508
This brings back the `Fill Volume` and `Exterior Bandwidth` inputs in
the Mesh to Volume node and modifier. Those existed in Blender 3.5 but
were removed in 700d168a5c because the way they were
implemented did not use the openvdb api in the right way.
While it's rare that people turned off the `Fill Volume` option, the
exterior bandwidth was used more and can have significant impact on
the result. Furthermore, there is no clear replacement for the
functionality.
Therefore, we decided to roll back the changes in 3.6 to avoid breaking
compatibility. We intend to keep the changes in 4.0 for now, but need
to work on a more clear short term replacement for the removed
functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/109297
This brings back the `Fill Volume` and `Exterior Bandwidth` inputs in
the Mesh to Volume node and modifier. Those existed in Blender 3.5 but
were removed in 700d168a5c because the way they were
implemented did not use the openvdb api in the right way.
While it's rare that people turned off the `Fill Volume` option, the
exterior bandwidth was used more and can have significant impact on
the result. Furthermore, there is no clear replacement for the
functionality.
Therefore, we decided to roll back the changes in 3.6 to avoid breaking
compatibility. We intend to keep the changes in 4.0 for now, but need
to work on a more clear short term replacement for the removed
functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/109297
With the previous fix to the node, 8a11f0f3a2, the new edge
indices are built with the changed corner vertices from a previous step
in the algorithm. That doesn't work for loose edges though, since they
aren't used by any face corners. The best solution I could come up with
was adding a second loop over the split vertices that adjusts the vertex
indices of loose edges. This can be skipped when there are none.
Pull Request: https://projects.blender.org/blender/blender/pulls/109262
Exposing both the option not to use pinned islands and to skip pinned
islands in the same drop-down was confusing.
Now there is a checkbox "Pin", when disabled, pinned UV's don't
have any impact on the packed result.
When enabled, the pin-method selects how pinned islands are handled.
Also remove the "ignore" option from the UI as this didn't fit well with
other methods of handling pinned islands. Instead, islands to be ignored
can be de-selected by the user.
Ref !108733.
When packing the largest islands, if the alpaca turns out to be tighter
than all of the other packers, then use alpaca on the large islands
and small islands together in one pass instead of two.
Move `GeometrySet` and `GeometryComponent` and subclasses
to the `blender::bke` namespace. This wasn't done earlier since
these were one of the first C++ classes used throughout Blender,
but now it is common.
Also remove the now-unnecessary C-header, since all users of
the geometry set header are now in C++.
Pull Request: https://projects.blender.org/blender/blender/pulls/109020
Until point clouds support multiple materials, just copy
the material from the first point cloud. This approach is the
same as for texture coordinate of meshes, active color attribute
of custom data, etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/108990
The split edges code had a complex method of merging duplicate edges,
going backwards to avoid shifting elements in a vector. Sometimes it
could result in incorrect corner edge indices though, if it moved an
index that matched one of the local variables (I think! I've bee
trying to understand this all day and still struggling). Instead,
replace it with a `VectorSet` that handles the deduplication by
itself, and avoid creating the new edges until the end.
I think this code could still be simpler if we tried to reduce the
amount of things happening at the same time, making more code
deal with the input or final state rather than an in-between one.
But to avoid making the change too complicated I stopped here.
Pull Request: https://projects.blender.org/blender/blender/pulls/108826
Before 4369627e71, the Mirror modifier merge did not interpolate
customdata.
Previously, the customdata was simply copied from the original vertex
during the merge, resulting in the retention of flags such as
`MVERT_SKIN_ROOT`.
This fix could just repeat that behavior for mirror. But these flags
can be useful in other cases, so this commit re-adds them to the
resulting merged vertex.
Although this can generate geometries with multiple roots on the same
island, there are different scenarios in which this can happen.
Therefore, multiple roots on the same island is not necessarily
considered a bug.
Pinning information was accidentally skipped inside of the
UV packing engine because of their ordering.
This was most noticeable when using the "Bounding Box" shape
method, causing some pinned islands to be moved when they
should have been locked in place.
