A new parameter, topology influence, is added that causes the
join_triangles operator to prioritize edge joins that create quads with
sensible geometry relative to existing quads, instead of selecting the
'flattest' and 'squarest' next pair and then leaving leftover triangles
with no partners to merge with.
This produces its best results with the face and shape thresholds set to
180 degrees (no hard limits as a restriction against merging) and
topology influence somewhere between 100-130%, depending on the mesh.
Too low and many parallelograms and triangles are left, too high and the
algorithm tries too hard and starts making errors.
Note that both quads already present in the selection, as well as the
quads that are generated during the operator, will influence the
topology around them. This allows the modeler to manually merge a few
quads in key areas of the mesh, as a hint to the algorithm, indicating
what result they way they want to see, and the algorithm will then take
those quads into account and try to build around them according to the
modeler's guidance.
A new checkbox to leave only the remaining triangles selected has also
been added. This helps users visualize what remains to be fixed.
Ref !128610
In multi-edit mode, the select non-manifold function would exit with
an error if any mesh was in face mode.
While in practice the mode is synced between meshes, it's possible for
them to get out of sync with multiple scenes.
Editing in the middle of a loop on all edit-objects would change their
selection based on the internal order, leaving some unhandled,
returning canceled even though changes where made.
Resolve by checking the selection mode in the operators poll function,
then ensure all edit-meshes selection modes match the active object.
- Track changed state, skip selection updates when unchanged.
- Skip hidden geometry early in iterators,
using "continue" instead of a code-block since this is such a common
check, avoid mixing this with other logic.
- Use full sentences in comments, minor corrections/improvements.
Adds a new "Select by Trait" option to select all 3-poles, 5-poles, etc.
Given the impacts of 3 & 5-poles in topology, operator default is to
select all poles which do not have 4 edges to allow easy inspection.
Select connected vertices/edges/faces based on the mode.
Ref: !128493
This commit forcibly rebuilds the PBVH whenever the number of verts is
changed by an operation, additionally, the related deform variables are
freed when undoing geometry steps now to ensure data remains consistent.
Pull Request: https://projects.blender.org/blender/blender/pulls/128145
`workspace->runtime->status` is not empty, which gave perference to
existing text instead of the modal operator keys in `uiTemplateInputStatus()`.
To fix this for bisect operator, clear `status` vector in modal
function.
Pull Request: https://projects.blender.org/blender/blender/pulls/127449
This replaces the older dynamic c array macros with blender::Vector in
bmesh_polygon_edgenet. This is the only remaining use of the old array
machinery and removal of `BLI_array.h / .c` can happen immediately
afterwards.
See #103343
Pull Request: https://projects.blender.org/blender/blender/pulls/119975
And same for the `copy_layout` function. These functions do not free any
potentially existing data in destination, but expect it to be uninitialized.
Hopefully these new names will make it more clear and avoid bugs like #122160.
Bridge could delete all faces & then fail to perform the bridge
operation. In this case the mesh was still modified.
Resolve by tracking the changed state, run updates when any changes are
made.
In `mesh_join_offset_face_sets_ID()`, `.sculpt_face_set` is
modified but the `finish()` call wasn't present on the
`SpanAttributeWriter`, leading to warnings and potentially broken
data. This is now fixed.
This reverts commit f3c32a36bc and the two followups.
The commit caused issues with both the operator and the modifier.
The operator could be fixed, for the modifier this needs deeper
investigation (see #124836 for a bit more info on this).
Until a better solution is found it is just better to go back to
previous behavior.
Reintroduces #103562 for now
Pull Request: https://projects.blender.org/blender/blender/pulls/125499
Replace the `BKE_scene_cursor` functions with member functions
of the `View3DCursor` DNA struct. This makes using the cursor's
transform simpler, especially in newer C++ code.
Pull Request: https://projects.blender.org/blender/blender/pulls/124903
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
This got superseeded by the "super knife" in 421823e34e 14 years ago
it seems, it cannot be executed atm. (and even if reactivated, it
crashes in multiple places).
Stumbled over this while checking on usages of
#BM_custom_loop_normals_to_vector_layer /
#BM_custom_loop_normals_from_vector_layer (to add this to more tools),
and apparently this outdated piece of code got an update in 93c8955a72
:) -- work on adding this to our "real" Knife is upcoming in another
PR...
Pull Request: https://projects.blender.org/blender/blender/pulls/124970
This was changed in [0] & [1] when replacing `float[3]` with `float3`.
However copying by value wasn't needed for the fix.
[0]: 7249b78b6b
[1]: efd3c4b3c9
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
The problem was basically that, after efd3c4b3c9, `test_cagep` started
to be used without being calculated.
`test_cagep` represents the closest 3D point on an edge.
The solution was to edit the `knife_snap_edge_constrained` function to
calculate the `test_cagep` instead of the `closest_ss` (which is the
projected point).
Calculating `test_cagep`(3D) instead of `closest_ss`(2D) is
advantageous as we avoid matrix transformations and achieve more
precision.
We also deduplicate the code a bit since `closest_ss` can be obtained
by projecting `test_cagep`.
This commit also adds comments to the code, and renamed some variables
and functions for more clarity.
Pull Request: https://projects.blender.org/blender/blender/pulls/124701
For non-trivial custom data types, the undo system did a shallow copy of the
base array which implicitly transferred ownership of the data to the undo
system. Combined with implicit sharing, this was hacky at best, and quite
wrong at worst, since it freed the implicit sharing info incorrectly.
To fix this, free the mesh custom data with the standard function for that
and add the non-trivial layers to the undo state using implicit sharing to
avoid another copy.
Alternative to #123894 and #123884.
Pull Request: https://projects.blender.org/blender/blender/pulls/123991
Although c9fa73a379 made the problem worse. The incorrect to snap to
edges when one of their vertices is behind the viewer is much older.
The problem occurred because, in perspective mode, when we project a
vertex with negative "zfac", its projected value is undefined as it
depends on the position of the other vertex.
Thus, both the distance test and the lambda in these cases were wrong.
The solution was to calculate the snap point directly in 3D, using
`closest_ray_to_segment_v3` and avoiding projecting the edge.
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
These operators in sculpt mode affect hidden geometry which is undesirable.
- bpy.ops.sculpt.face_set_edit
- bpy.ops.sculpt.face_sets_init
- bpy.ops.sculpt.face_sets_create(mode='SELECTION')
- bpy.ops.mesh.paint_mask_extract()
- bpy.ops.mesh.paint_mask_slice()
This PR adds checks for hidden faces in these operators.
For operator `bpy.ops.sculpt.face_sets_init` it also modifies the way
face sets indices were generated so generated indices is unique. This
is needed so new initialized face sets do not get same indices as hidden
face sets.
For generating unique face set index I have created a set container
which stores hidden face sets indices. Before assigning indices to a
face set it checks if it is already in set container, if it is then
it'll keep increasing index by 1 until it is not in set container.
Modifying Operator `bpy.ops.mesh.paint_mask_slice()` is little complex,
it will not affect hidden geometry only when fill holes option is
unchecked, because currently filling hole code does not take hidden
geometry into account and because of this in some cases hidden part
of geometry can be trapped inside mesh.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/119168
`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
`Weight` & `Threshold` sliders should **not** show in case of `Type` :
`Custom Normal` and **should** show for both `Type` : `Face Area` &
`Type` : `Corner Angle`
In code, it looks like we are gathering `loop_weight` with `val`.
- this is always 1.0 for `EDBM_CLNOR_AVERAGE_LOOP`
- this is taken from `BM_face_calc_area` for
`EDBM_CLNOR_AVERAGE_FACE_AREA`
- this is taken from `BM_loop_calc_face_angle` for
`EDBM_CLNOR_AVERAGE_ANGLE`
Code then compares not equal those values with given threshold, but for
`EDBM_CLNOR_AVERAGE_LOOP` this will never trigger (since all values are
the same), thus `count` is always zero which makes the effective
`n_weight` always 1. So all loop split normals are averaged for a vertex
with the same weight (seems to make sense to me -- at is just plain
average)
Long story short: the condition to show `Weight` & `Threshold` sliders
is just flipped (these only apply for the methods that take neighbor
faces into account).
Pull Request: https://projects.blender.org/blender/blender/pulls/121864
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
While using the mesh Bevel operator, show the changing values on the
area header and keymap entries on the Status Bar using the new system
that shows icons and toggles. Approximately 30% shorter display.
Pull Request: https://projects.blender.org/blender/blender/pulls/121796
