* Uses const where possible
* Joins declaration with assignment
* Use std::array where possible instead of C-style array
* Use float3 instead of C-style array for position and normal
* Reduces scope of variables where possible
Pull Request: https://projects.blender.org/blender/blender/pulls/135336
This commit changes usages of `GHash` inside `bmesh_log.cc` into their
equivalent `blender::Map` declarations and functions.
Additionally, some debug functions are put inside a NDEBUG section
instead of being kept in a broken state behind `#if 0`
Pull Request: https://projects.blender.org/blender/blender/pulls/135276
- Refactor tagging logic into a function to remove duplicate code
The two phases of tagging were identical logic just with the variables
and tag values swapped. This change ensures the two loops use matching
behavior.
- Adjust iteration to prevent restarting from the beginning of the mesh
after each island.
- Simplify and speed iteration tests.
testing to ensure v->e is non-null is redundant - verts with no edges
would never have passed `bm_vert_dissolve_fan_test` in the first
place, so can't be tagged as `VERT_INDEX_INIT`.
Re-testing `bm_vert_dissolve_fan_test(v)` is redundant - it was
checked above, and during tagging, the topology does not change.
Topology only changes later, after tagging is complete.
Therefore it's guaranteed to return the same result as the first time.
- Simplify loop logic, rename vars for clarity
offset and nth were constants, and depth was what causes alternation.
However none of that math is necessary - it can simply be done with
call order.
'seek_a' and 'seek_b' were renamed to what they actually are - lists
of verts that are tagged for collapse and ignore, respectively.
Further, by checking if any verts were tagged during the first
iteration pass, the second iteration pass can be avoided entirely if
it will perform no work.
Ref: !135212
The existing behavior of the grid fill operator requires a loop of
boundary or wire edges to be selected. This algorithm tries to fit a
grid of quads into the edge loop. It also works if you select two of the
four 'rails' of an edge loop.
This new behavior allows running grid fill after selecting faces.
If the algorithm sees that a set of faces are selected, it separates
all the faces, and then attempts to grid from their exterior boundary
using the exact same logic it normally uses for interior boundaries.
This all assumes the user has selected a set of faces with an outside
border that works with grid fill. (has one clear exterior loop with an
even number of edges) If not, grid fill will halt, and notify the user
of the error, exactly the way that it already did before.
Once the grid fill is complete and successful,
the existing faces which were replaced get deleted.
UVs (including at UV island boundaries) are interpolated properly,
as are custom-data on verts, edges, faces, and face corners.
At the edges of the selection, the edges/faces/face corners that are
selected contribute, but the custom-data outside the selection does not.
This also resolves non-deterministic behavior.
The previous behavior of `edbm_grid_fill_prepare` found the vertex with
the largest angle, then walked the edge loop until it found one out of
the three best remaining corners. This established one edge of the grid
area, and the second edge was found by symmetry.
However, the direction that the algorithm walked the loop
(and therefore which second corner was found) was essentially arbitrary.
The new behavior first finds the vert with the largest angle,
then finds the vert with the second largest angle,
(after excluding the diagonally opposite corner from the first vert),
and selects the edge between those two verts.
Ref !129318.
Previously we generally expected CustomData layers to have implicit
sharing info, but we didn't require it. This PR clarifies that we do
require layers with non-null data to have implicit sharing info. This
generally makes code simpler because we don't have to have a separate
code path for non-shared layers. For example, it makes the "totelem"
arguments for layer freeing functions unnecessary, since shared data
knows how to free itself. Those arguments are removed in this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/134578
Replace `const char *` with `StringRef` for the API in `BKE_attribute.h`.
The benefits are slightly simpler code and possibly slightly improved
performance through avoiding the need to measure string length.
Pull Request: https://projects.blender.org/blender/blender/pulls/134183
The newly added "tangent_pair" calculation functions meant the names
didn't read well in some cases, use this style of naming for clarity:
- BM_face_calc_tangent_from_*
- BM_face_calc_tangent_pair_from_*
It was possible two quads at right-angles to each other would accumulate
a "tangent" that was co-linear with the it's normal.
Resolve this by calculating two tangents for each face, then using the
accumulated tangent that's least co-linear with the accumulated normal.
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
When moving UV seams from special custom data types to attributes,
I considered them similar to mesh selection or visibility which are
"internal" attributes that aren't accessible procedurally and are
hidden from the UI. In retrospect that was the wrong decision; users
expect UV seams to behave more like bevel weights, and that makes sense.
This PR makes UV seams accessible in modifiers (geometry nodes) by
removing the leading period from the attribute name that indicated their
internal status.
The change of the attribute name is a breaking change of the API to some
extent, even though it's technically only mesh data. To mitigate that
issue, the `mesh.attributes["name"]` lookup function is modified to
support both the old and new names. Versioning code renames the
attribute to the new name when loading older files, and renames the
new name to the old name when saving files. That handling will be
removed as a breaking change in 5.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/129803
Move `CD_CUSTOMLOOPNORMAL` to the newly added
`CD_PROP_INT16_2D` generic attribute type. This is similar to
previous commits moving specific custom data types.
The attribute name is `custom_normal`. When the attribute with
that name is on the face corner domain, the code will interpret it
as stored in the existing deformation-invariant spherical coordinate
space.
The API remains the same, with the additional opportunity to edit
custom normal data as an attribute directly (which admittedly is fairly
unintuitive currently).
See #130484.
Pull Request: https://projects.blender.org/blender/blender/pulls/130689
Rotating an edge deletes the edge and creates a new edge
however these edges were being iterated over and had their indices
checked.
In practice this wasn't causing use-after-free errors because the
edges are part of a BLI_mempool, nevertheless using freed elements of a
memory-pool should be avoided.
From Rob Blair's PR https://projects.blender.org/blender/blender/pulls/126309 .
In the code that clamps the bevel amount, the existing code could get
a denominator of 0 (from a tangent of a certain angle).
This code uses a different calculation (diagram in the PR) that clamps
when the projections of four specific edges onto another edge consumes
the whole length of that edge.
