Blender currently has 2 algorithms for merging vertices:
- `BKE_mesh_merge_verts`;
- `blender::geometry::create_merged_mesh`
`BKE_mesh_merge_verts` has a simplified algorithm to work with Array,
Mirror and Screw modifiers. It doesn't support merge results that would
create new faces. However it has shortcuts to be more efficient in
these modifiers.
`blender::geometry::create_merged_mesh` tries to predict all possible
outcomes. So it's a more complex. But it loses in performance to
`BKE_mesh_merge_verts` in some cases.
The performance comparison between these two depends on many factors.
`blender::geometry::create_merged_mesh` works with a context that has
only the affected geometry. Thus a smaller region of the mesh is read
for duplicate checking. Therefore, the smaller the affected geometry,
the more efficient the operation.
By my tests `blender::geometry::create_merged_mesh` beats
`BKE_mesh_merge_verts` when less than 20% of the geometry is affected
in worst case `MESH_MERGE_VERTS_DUMP_IF_EQUAL` or 17% in case of
`MESH_MERGE_VERTS_DUMP_IF_MAPPED` .
For cases where the entire geometry is affected, a 30% loss was noticed,
largely due to the creation of a context that represents the entire mesh.
Co-authored-by: Germano Cavalcante <germano.costa@ig.com.br>
Pull Request #105136
Using spans instead of raw pointers helps to differentiate ararys from
pointers to single elements, gives bounds checking in debug builds, and
conveniently stores the number of elements in the same variable.
Also make variable naming consistent. For example, use `loops` instead
of `mloop`. The plural helps to clarify that the variable is an array.
I didn't change positions because there is a type mismatch between
C and C++ code that is ugly to manage. All remaining code can be
converted to C++, then that change will be simpler.
Pull Request #105138
This code seems to be left over from before edges, polys, and loops were
stored in CustomData. They are already copied by the CustomData copy
calls directly above, which already deal with every other layer.
Invalid node trees (e.g. when nodes are linked in a cycle) can not be
evaluated and the viewer is not available in them. This commit just adds
some null checks to handle this case more gracefully.
This reverts commit 19222627c6.
Something went wrong here, seems like this commit merged the main branch
into the release branch, which should never be done.
As described in #104171, add an operator that creates a new node group
that contain the current node group and named attribute nodes to deal
with the outputs. This saves manual work when moving a high-level
modifier to the node editor for better procedural control.
Pull Request #104546
When building a node group that's meant to be used directly in the
node editor as well as in the modifier, it's useful to be able to have
some inputs that are only meant for the node editor, like inputs that
only make sense when combined with other nodes.
In the future we might have the ability to only display certain assets
in the modifier and the node editor, but until then this simple solution
allows a bit more customization.
Pull Request #104517
As described in #95966, replace the `ME_EDGEDRAW` flag with a bit
vector in mesh runtime data. Currently the the flag is only ever set
to false for the "optimal display" feature of the subdivision surface
modifier. When creating an "original" mesh in the main data-base,
the flag is always supposed to be true.
The bit vector is now created by the modifier only as necessary, and
is cleared for topology-changing operations. This fixes incorrect
interpolation of the flag as noted in #104376. Generally it isn't
possible to interpolate it through topology-changing operations.
After this, only the seam status needs to be removed from edges before
we can replace them with the generic `int2` type (or something similar)
and reduce memory usage by 1/3.
Related:
- 10131a6f62
- 145839aa42
In the future `BM_ELEM_DRAW` could be removed as well. Currently it is
used and aliased by other defines in some non-obvious ways though.
Pull Request #104417
Subdivision surface efficiency relies on caching pre-computed topology
data for evaluation between frames. However, while eed45d2a23
introduced a second GPU subdiv evaluator type, it still only kept
one slot for caching this runtime data per mesh.
The result is that if the mesh is also needed on CPU, for instance
due to a modifier on a different object (e.g. shrinkwrap), the two
evaluators are used at the same time and fight over the single slot.
This causes the topology data to be discarded and recomputed twice
per frame.
Since avoiding duplicate evaluation is a complex task, this fix
simply adds a second separate cache slot for the GPU data, so that
the cost is simply running subdivision twice, not recomputing topology
twice.
To help diagnostics, I also add a message to show when GPU evaluation
is actually used to the modifier panel. Two frame counters are used
to suppress flicker in the UI panel.
Differential Revision: https://developer.blender.org/D17117
Pull Request #104441
Straightforward port. I took the oportunity to remove some C vector
functions (ex: copy_v2_v2).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
Straightforward port. I took the oportunity to remove some C vector
functions (ex: `copy_v2_v2`).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
This reverts commit 11a9578a19.
Reverting this because there was a miscommunication between Simon and me. Shortly
before I committed the change, Simon noticed that there are cases when "Hide Value"
is checked to hide the value in a group node, but we still want to show the value
in the modifier.
When the "Hide Value" option of a group input is enabled, only its name
is displayed in group nodes. Modifiers should have the same behavior.
However, for modifiers, only showing the name does not make sense
when the user can't edit the value. Therefore the value is not shown at all.
Simon mentioned that this gets in the way more than it helps. No geometry
sockets currently show up in the modifier panel. People may build node groups
that have multiple geometry inputs that can be used when the group is used
as node instead of as modifier.
In the future we could also allow e.g. choosing an object to pass into a geometry
socket. That has the problem that we'd also have to duplicate other functionality
of the Object Info node (original vs. relative space).
After object-mode undo (memfile undo), the value wan't lost, but the
property would be temporarily converted back to integer type in order
to be forward compatible. Now only use the forward compatible
writing when writing undo steps. Auto-saves and similar files are
currently not forward compatible anyway.
This also fixes the layout of boolean properties with the field toggle
visible. This was discussed in the most recent geometry nodes submodule
meeting.
This uses the changes from ef68a37e5d to create IDProperties
for exposed boolean sockets with a boolean type instead of an integer
with a [0,1] range. Existing properties and values are converted
automatically.
For forward compatibility, the properties are switched to the integer
type for saving. Otherwise older versions crash immediately when opening
a newer file. The "Use Attribute" IDProperties aren't changed here,
since that wouldn't have a visible benefit.
Differential Revision: https://developer.blender.org/D12816
Use a consistent style for declaring the names of struct members
in their declarations. Note that this convention was already used in
many places but not everywhere.
Remove spaces around the text (matching commented arguments) with
the advantage that the the spell checking utility skips these terms.
Making it possible to extract & validate these comments automatically.
Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo`
which were using brief descriptions.
Currently you can retrieve a mutable array from a const CustomData.
That makes code unsafe since the compiler can't check for correctness
itself. Fix that by introducing a separate function to retrieve mutable
arrays from CustomData. The new functions have the `_for_write`
suffix that make the code's intention clearer.
Because it makes retrieving write access an explicit step, this change
also makes proper copy-on-write possible for attributes.
Notes:
- The previous "duplicate referenced layer" functions are redundant
with retrieving layers with write access
- The custom data functions that give a specific index only have
`for_write` to simplify the API
Differential Revision: https://developer.blender.org/D14140
Similar to the corresponding properties on node sockets, only adjust
the soft range. Because group nodes only have soft limits, groups
should generally be able to accept these inputs anyway. The benefit
of only using a soft range is that it allows choosing a more user-
friendly default range while keeping flexibility.
Move the `ME_SHARP` flag for mesh edges to a generic boolean
attribute. This will help allow changing mesh edges to just a pair
of integers, giving performance improvements. In the future it could
also give benefits for normal calculation, which could more easily
check if all or no edges are marked sharp, which is helpful considering
the plans in T93551.
The attribute is generally only allocated when it's necessary. When
leaving edit mode, it will only be created if an edge is marked sharp.
The data can be edited with geometry nodes just like a regular edge
domain boolean attribute.
The attribute is named `sharp_edge`, aiming to reflect the similar
`select_edge` naming and to allow a future `sharp_face` name in
a separate commit.
Ref T95966
Differential Revision: https://developer.blender.org/D16921
An apostrophe should not be used because it is not a mark of plural,
even for initialisms. This involves mostly comments, but a few UI
messages are affected as well.
Differential Revision: https://developer.blender.org/D16749
Using run-time members in the surface modifier complicated code-review
and caused an unnecessary renaming in `dna_rename_defs.h`.
Also rename:
- `x` -> `vert_positions_prev`.
- `v` -> `vert_velocities`.
- `cfra` -> `cfra_prev`.
