The attribute API defined in `attribute.cc` was dependent on
the assumption that `ID`s are always the "direct" owners of attributes.
For Grease Pencil drawings, this is not the case. The Grease Pencil ID
stores the attributes for layers, and the attributes for drawings are stored
in `CurvesGeometry` on the drawings themselves.
In order to make use of `rna_attribute.cc`, we need that API to handle
other types of attribute owners.
This adds an `AttributeOwner` which is basically just a type and a
pointer. We replace the `ID` pointers and pass `AttributeOwner`s instead.
For cases where we have to do a switch based on the type, all the
types are handled and the `default` statment is left out. This ensures
that we get a compiler warning when a new `AttributeOwnerType`
is added.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/122765
A subtle error in 66da875488 mean that the existing selection
was overwritten instead of adding to the final flag on the result BMesh
element. Selection is often interpolated separately which is probably
why this mistake wasn't more observable earlier.
A subtle mistake in 66da875488 meant that existing selection
was overwritten instead of maintained in the BMesh utility functions for
copying element custom data and flags.
`BM_mesh_triangulate` is used in exporters (when the "Triangulate"
option is ON), the `Triangulate` modifier and currently also in the
`Triangulate` geometry node (even though there are plans to change this,
see !112264)
So in practice, exporters (Alembic/FBX/OBJ/Collada) were breaking
custom normals for game pipelines (unless everything was triangulated
beforehand).
This change builds upon 93c8955a72 (uses the use
`BM_custom_loop_normals_to_vector_layer` /
`BM_custom_loop_normals_from_vector_layer` pair of calls).
In the case of the `Triangulate` modifier, this had its own try at
preserving custom normals in 7d0fcaa69a -- doing very similar
things but as an option -- this is now removed (so it is always done,
which fits into "interpolate custom data if it's there" design that we have
nowadays).
NOTE: the "Triangulate Faces" operator already did the same
Pull Request: https://projects.blender.org/blender/blender/pulls/121871
This pull request adds an "Active Element" node that exposes the active
vertex, edge, or face index to the geometry node tool context. The
presence of an active element is available as a boolean.
This node enables the creation of "active-to-selected" style operators.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121333
Exposed by 6c774feba2
`BM_mesh_decimate_dissolve_ex` sets up `DelimitData` with layer offset
(start), size and end so that `bm_edge_is_contiguous_loop_cd_all` can
check a range of edges for being contiguous.
The way `cd_loop_offset_end` is calculated is wrong though, it does not
take the actual start into account (this has to be added to fix the
bug). When it is wrong, it can happen that start and end are the same,
so no check actually takes place and no delimiting edges are found.
It seems that prior to 6c774feba2 the customdata layer always had an
offset of zero, so never really showed in practice (at least I couldnt
make it break in 3.4), but after 6c774feba2 we can at least observe the
following:
- when creating a bmesh, an offset would to the uv layer would still be
zero in my tests
- however, as soon as we iterate loops of a face (as done in the
report), we get an additional layer `CD_BM_ELEM_PYPTR`
- this then changes the offset
- `BM_uv_map_get_offsets_from_layer` seems to do the right thing afaict
So to resolve, just add the "start" offset to the end, to get the right
range.
NOTE: there is a very similar `DelimitData` used in
`bmesh.ops.join_triangles` and the way in which `bm_edge_delimit_cdata`
sets up te range is exactly like what this PR proposes.
Pull Request: https://projects.blender.org/blender/blender/pulls/121033
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
For example, creating the "position" attribute with the wrong name or type
could crash Blender when exiting edit mode. This is because some data isn't
stored as attributes in Blender, and the attribute API doesn't work very well
with BMesh.
Two parts to the solution:
- Remove builtin attributes with incorrect domains or names when
converting from BMesh to Mesh.
- Add error messages when creating builtin attributes in edit mode. It's still
possible to create name-convention attributes, because Blender should be
able to handle different types and domains for them.
Pull Request: https://projects.blender.org/blender/blender/pulls/119110
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
This PR adds a new method to BMLog to explicitly make the intent of
searching for an entry clear and adjusts the calling code in `pbvh_bmesh`
to utilize it.
Pull Request: https://projects.blender.org/blender/blender/pulls/118543
In this commit, a temporary mesh is created representing the edit mesh.
This mesh is then used in the Edit Mesh snapping system instead of the
BMesh.
By using a Mesh object for snapping, we remove a considerable amount of
code and use a more optimized version of snapping.
This simplifies the code and makes it easier to implement new features.
## Performance test: Face + Edge + Vert
| | Cache | Gen. Snap |
|--------|-----------|-----------|
| Before | 680.88 ms | 0.1250 ms |
| After | 489.06 ms | 0.1064 ms |
| Improv | 28.65% | 14.88% |
## Performance test: Face
| | Cache | Gen. Snap |
|--------|-----------|-----------|
| Before | 293.90 ms | 0.0230 ms |
| After | 411.92 ms | 0.0256 ms |
| Improv | -40.15% | -11.30% |
Pull Request: https://projects.blender.org/blender/blender/pulls/117047
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Except for vertex groups and a few older color types, these
are generally replaced by newer generic attribute types.
Also remove some includes of DNA_mesh_types.h, since it's
included indirectly by BKE_mesh.hh currently.
