This argument is always passed as null. Removing it simplifies the
transition to `AttributeStorage`. Nowadays it seems that most more
complicated interpolation needs are not handled directly by the
CustomData system.
Pull Request: https://projects.blender.org/blender/blender/pulls/145197
Use of BM_faces_join_pair can result in an invalid mesh with doubled
faces. [0] added an assert to identify when this could occur.
This case has been inspected, and allowing the auto-join logic in
BM_faces_join_pair() to delete the doubled face does not negatively
impact iteration or processing:
1. The eheap and eheap_table used here deal only with edges, not faces.
2. Loop iteration is unchanged.
A conversion to use of BM_ITER_MESH_MUTABLE is not applicable because
the iteration is done on the edge heap, not the mesh.
3. The recomputation of the face normals of each combined face still
works properly.
Ref !144653
[0]: 702efd6846
PR https://projects.blender.org/blender/blender/pulls/144233.
Fix#142296 performance regression caused by merging UV positions
based on face area weights, replacing it with mean average weights
computation. The former method resulted in higher probability in making
subdivision cache invalid between frame updates and thus causing expensive
recreation of blender::bke::subdiv::OpenSubdiv_Evaluator object.
While this fix isn't directly answering a question why specific UV position
updates would cause this reevaluation of subdivision object, it fixes
the performance regression caused by #139595 PR.
Support limiting the merge by connected geometry.
This is useful for operations such as bevel where it's not desirable
for the merge to connect isolated surfaces.
Accessible from the Python API, no user visible changes.
Ref !144036
The check that triangles from a quad point away from each other wasn't
sufficient to avoid creating bow-tie quads.
Resolve by picking the most planar triangle pair.
This is the second time I've needed a function to find an attribute by
name on all attribute domains, with a third time coming soon. It seems
time to put this in a BMesh header.
Pull Request: https://projects.blender.org/blender/blender/pulls/144039
If the BMesh already has a "custom_normal" attribute with the wrong
type, the call to `BM_lnorspace_update` won't be able to add the
attribute with the expected name, and the bevel code ends up using an
invalid offset to access the data.
For the fix, first just guard against that case. But also make sure the
harden normals functionality still works when the input mesh has free
normals. They will no be converted to tangent space normals as
necessary, in bevel and in other BMesh code that requires that
custom normal storage format.
Pull Request: https://projects.blender.org/blender/blender/pulls/143489
While all callers currently operate on the selection, the function
supports other header-flags, so check the selection is being used
before updating & flushing the selection.
The bmesh.ops.split operator could include deleted edges as the keys
for `boundary_map`.
Resolve by replacing deleted edges with so the same edge is used for
the key & value, needed so the boundary_map can access the entire
boundary, even when it's source edges have been deleted.
Fix#142045 crash on performing bevel operation on border edges.
When user selected both border edges and neigboring edges
(parallel to those border egdes) for the bevel operation,
the former were omitted during construction of BevVert objects
but their initial UV connectivity were recorded during call
to determine_uv_vert_connectivity function - specifically BMLoop
pointers were stored in BevelParams::uv_vert_maps member.
This later caused issues after rebuilding existing polygons
(bevel_rebuild_existing_polygons) since previously recorded
BMLoop pointers became invalid for border edges but still were
stored in uv_vert_maps (uv_vert_map_pop function was not called
for them since those loops were not related to BevVert objects).
This caused crash when accessing UV positions, when providing
invalid loop pointer to BM_ELEM_CD_GET_FLOAT_P function in bevel_merge_uvs.
The C++ Vector container has the benefits of the older C type,
along with improved performance, better type and memory safety,
and significantly improved ergonomics.
Pull Request: https://projects.blender.org/blender/blender/pulls/141759
* Remove bke, ed and wm prefixes
* Add prefixes like: geom, object, blend, lib.
* Shorten some category names
* A few log level changes to improve --log-level info output
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
Correct problem where face split inadvertently triggered the
un-triangulate detection logic in places due to freshly added diagonals.
Defer face split until after tagging is complete so the new edges don't
interfere with edge counting.
Ref !141511
Adjust angle threshold defaults to dissolve verts as before,
while preserving selected geometry.
The new behavior works as follows:
- If a dissolve terminates on an edge loop or the the corner vert of a
face, do the dissolve.
- If a set of dissolve edges (either a chain, or a set of 3+ edges)
crosses a loop cut, do the dissolve.
- If a chain of dissolve edges touch the corner of an unselected face,
and then leave in a different direction without crossing a loop cut,
preserve that vert. Just because the selection touches it doesn't mean
it should be altered.
- If a dissolve edge is separating two triangles,
then the face join creates a quad. Users generally prefer
and strive to create meshes that contain quads.
Instead of destructively dissolving the corners of the quad and
automatically turning it to a triangle or wire,
instead prefer to preserve the quad.
Ref !141097
Fix#140813 crash, when bevel operation doesn't choose proper representative
face (called frep, facerep or rep_face in code). In such scenario a nullptr
would be assigned to uv_face->attached_frep field in register_uv_face function
and later, as a result of that, BM_face_vert_share_loop function would crash
during call to update_uv_vert_map function.
This commit also includes additional safety check in register_uv_face function,
as well as removes compiler warning about assigned but unused center_bme variable.
This is from PR https://projects.blender.org/blender/blender/pulls/140864
but applied to the 4.5 release branch.
Fix#140813 crash, when bevel operation doesn't choose proper representative
face (called frep, facerep or rep_face in code). In such scenario a nullptr
would be assigned to uv_face->attached_frep field in register_uv_face function
and later, as a result of that, BM_face_vert_share_loop function would crash
during call to update_uv_vert_map function.
This commit also includes additional safety check in register_uv_face function,
as well as removes compiler warning about assigned but unused center_bme variable.
This is from PR https://projects.blender.org/blender/blender/pulls/140864
but applied to the 4.5 release branch.
Problem - offset collision check for bevels did not consider the reduced
offset when using bevel edge weights, thus greatly reducing the allowed offset.
Solution - calculate the offset check using the weighted value and not
the full offset.
Alternatives - Since this error was introduced in the patch dd334faa58
a solution would be to revert the patch. This is not optimum since the
patch did correct the inf/inf condition in the offset calculation (ex at
90 degs, tan is 1/0).
Limitations - This patch is a correction to return the bevel function to
it's previous abilities. Further work is needed to properly handle edge
offset interference when looking at n-gons with reflex angles. There are
also situations where the bevel operation exceeds the checked offset distance
(exs. inner arc spread and bevel profiles that are not normal to the bevelled edge).
Fix#79163 bug related to the bevel operation producing disconnected UVs for
new bevel faces. This change replaces previous approach using scattered and
selective usage of functions: bev_merge_uvs, bev_merge_edge_uvs and
bev_merge_end_uvs with one coherent technique for all stages of the bevel operation.
It is utilizing a concept of loop (BMLoop) buckets to keep track of UV vertices
that should be merged at the end of bevel operation by a single call to
bevel_merge_uvs function. This approach doesn't touch initial UV position
calculation done by interpolation algorithm in bev_create_ngon function and
keeps the concept of representative faces (called frep, facerep or rep_face in
code) to help decide to which bucket specific loops should be assigned.
This is from PR https://projects.blender.org/blender/blender/pulls/139595,
which has more explanation and discussion.
Fix#79163 bug related to the bevel operation producing disconnected UVs for
new bevel faces. This change replaces previous approach using scattered and
selective usage of functions: bev_merge_uvs, bev_merge_edge_uvs and
bev_merge_end_uvs with one coherent technique for all stages of the bevel operation.
It is utilizing a concept of loop (BMLoop) buckets to keep track of UV vertices
that should be merged at the end of bevel operation by a single call to
bevel_merge_uvs function. This approach doesn't touch initial UV position
calculation done by interpolation algorithm in bev_create_ngon function and
keeps the concept of representative faces (called frep, facerep or rep_face in
code) to help decide to which bucket specific loops should be assigned.
This is from PR https://projects.blender.org/blender/blender/pulls/139595,
which has more explanation and discussion.
Add an optional init function which operators
An alternative to [0] which missed Python API support (causing #140451).
While that could be resolved, tracking which "slots" have been set
would have to be flagged on every map/hash insertion which seems
excessive and is prone to bmesh operators failing if the flag is ever
missed. Prefer a simpler init function so dissolve edges doesn't have
a zero threshold.
Also support multi-line comment blocks in the generated API docs.
[0]: bd3a66a416
The BMesh python API was fully broken by this commit.
While the fix seems to be reasonably simple, it is safer for now to revert
the faulty commit, as the breakage is fairly impactful for people using 4.5
and/or 5.0 daily builds.
This reverts commit bd3a66a416.
The [Fix#125024: Bevel offset - eliminate divide by 0] (#126309)
in response to [Bevel Modifier creates unwanted geometries] (#125024)
created "divide by 0" situations when checking for clamp overlap geometry
in the bevel modifier. This PR eliminates this undefined behavior.
Original PR by Rob Blair. Modified by make format and added
a needed include.
Restore the BM_vert_is_edge_pair(v) check that was present prior to
!134017. In that PR, the edge pair check was moved up, to a previous
iteration pass, that checked the angle thresholds. However, even though
pairs were checked before, the process of performing edge merges might
change a neighboring vert such that it is no longer an edge pair.
Therefore it is necessary to check a second time.
Resolves regression in [0].
[0]: e418f7b1f1
A bug that was introduced in !131645 where the number of verts eligible
for dissolve was reduced, to prevent dissolving unrelated verts.
That PR changed the code to only do the dissolve check on verts at the
ends of selected edges, which solved bug #109765. However, this didn't
properly account for dissolving only one edge in a chain in a face pair.
This could result in cases where one of the vertices should be checked
but wasn't - if it wasn't selected.
Now when an edge is dissolved, each of its verts is checked,
and if it's in a chain, the VERT_MARK tag is moved down the
chain until it finds its natural endpoint.
Ref !139959.
