It seems that this was 'fine', as non-trivial data in `BVHTreeFromMesh`
appear to be 'safe' when simply zero-initialized instead of being
properly constructed.
Note that this 'calloced' data was already 'MEM_deleted', this is
currently considered as a valid use-case unfortunately, otherwise the
issue would have been detected earlier.
Directly use 'copy' `MEM_new` code instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/135862
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Grease Pencil dash modifier wasn't merging strokes from strokes that are
unfiltered, resulted in only filtered strokes being shown afterwards.
This fix joins generated strokes with what's left behind so there's no
stroke missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/135705
Grease Pencil dash modifier wasn't merging strokes from strokes that are
unfiltered, resulted in only filtered strokes being shown afterwards.
This fix joins generated strokes with what's left behind so there's no
stroke missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/135705
When using Alembic procedurals, the Mesh Sequence Cache attempts to
replace the original geometry with a plain old cube. However, it never
frees this new cube geometry. Transfer ownership to the underlying
GeometrySet instead.
Investigating the scenario also showed that the `~AlembicProcedural`
dtor was removing an item from the `nodes` vector while iterating over
it, which triggers debug asserts on at least MSVC. I believe the removal
is unnecessary since this is the dtor and ASAN appears clean now.
Pull Request: https://projects.blender.org/blender/blender/pulls/134085
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
Resolve naming collisions for structs which could cause the wrong size
to be used allocating the `LaplacianSystem` when calculating mesh
weights from an armature.
Ref !135491
Adds the option to create a boolean socket that can be used as a panel toggle.
This allows creating simpler and more compact node group UIs when a panel
can be "disabled".
The toggle input is a normal input socket that is just drawn a bit differently in
the UI. Whether a boolean is a toggle input or not does not affect evaluation.
Also see #133936 for guides on how to add and remove panel toggles.
Pull Request: https://projects.blender.org/blender/blender/pulls/133936
Same was true for SimpleDeform.
Invert vertex group influence should only have an effect if there is a
group specified.
Shrinkwrap always uses a weight (gets weights via
`BKE_defvert_array_find_weight_safe` -- which gets full weight for no
group specified, rightfully so), if this gets inverted, we get no
influence at all.
Now move the inverting of the weights to `BKE_defvert_array_find_weight_safe`,
adjust the other callers accordingly (Bevel also does not need to check for a valid
vertexgroup beforehand).
Pull Request: https://projects.blender.org/blender/blender/pulls/121625
The fix 8af27ce27e assumed that
the `edit_hints->positions()` were always empty and that we would always
fallback to using the evalauted positions instead.
But if the edit hints are populated, this fails. In this case, we populate the
positions in `remember_deformed_positions_if_necessary`.
The fix makes sure that we write to the `edit_hint` positions if they are
populated.
Pull Request: https://projects.blender.org/blender/blender/pulls/135033
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
And replace nullptr arguments for tooltips in UI button
creation functions with std::nullopt. Though the distinction
between "no tooltip" and "empty tooltip" doesn't seem to exist,
it seems safer to keep the distinction since it existed with null before.
When calling the `lookup_or_add` functions on `MutableAttributeAccessor`
we need to make sure that the writer is actually created and the call
did not fail.
This fixes many of the instances where we would use an unchecked
attribute writer and potentially crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/134413
A bit less trivial than usual, since it was an 'array' of non-trivial
structs. Used a `blender::Array` instead.
NOTE: keeping changes to a minimum, there is much to refactor and
cleanup in this code.
Natural drawing speed fails for strokes that are pasted or duplicated.
This is due to the `init_time` attribute being transferred from previous stroke
to the new, resulted in the same values. This further calculates wrong
`build_factor` inside `get_factor_from_draw_speed`. To further explain
this, `gap_delta_time = -prev_end_time` which evaluates `start_time=0` for
the duplicated curve. To avoid this situation, make sure `gap_delta_time`
is positive. So `start_time` will be > 0.
Pull Request: https://projects.blender.org/blender/blender/pulls/134329
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
The stroke index was wrong when a influence filter is active in the
modifier, this would lead to crashes. Now corrected this by only
iterating duplicated strokes in front of the curves geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/134038
The issue was that the topology of the drawing changes when the bezier
curves get resampled to poly curves in the armature modifier.
This means that the crazyspace code fails to find deformed positions
with the same length as the original positions.
The fix does multiple things:
* First, we make sure that we create an `GeometryComponentEditData` in
weight paint mode.
* When the armature modifier runs, we remember the current positions in
this component.
* Then, we store the curve offsets and weights _before_ converting the
bezier curves.
* Finally we deform the positions stored in the edit hint component
(which have the same length as the original positions).
Since the resampling just adds new points, there might be a way to
avoid running the armature deformation a second time on the edit
hints, but I'll leave that for another day as a performance improvement.
In any case, this is only done when we actually need the deformation
(e.g. in weight paint mode when we paint the weights).
Pull Request: https://projects.blender.org/blender/blender/pulls/134030
The Subdivision Modifier used "Levels" and the Multiresolution Modifier used "Level". This difference is changed to be "Levels" for both, which aligns with similar UI terminology where plural forms indicate adjustable values, such as "Render Samples".
Ref blender/blender-manual#105098
The algorithm to calculate face corner normals had a vertex normal
input, with the intention to pre-populate corner normals for vertices
with no sharp connected edges. However corner normals are calculated
separately for these fully sharp vertices later anyway, so this whole
step was completely redundant. Removing the vertex normals calculation
reduces memory usage and improves performance. In a test file with a
character with custom normals, this changed improved the playback FPS
by 15%, from 41 to 47 FPS. The impact will usually be lower than that
but it should be noticeable in other scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/133884
The handling of influence vertexgroups was incomplete/inconsistent.
Some prior work was already done in 08539618cd, c452d5d9e8,
782a4c9d85, 0fd3f3c216, 434f94b254, 82ea972834, f6b820ccb7,
00968fe6db .
Now that the inverting is handled consistently, we can move that part
out of specific modifier code an into the generic retrieval function
`greasepencil::get_influence_vertex_weights` -- resulting in all
modifiers using it behaving the same.
There were some modifiers already handling
`GREASE_PENCIL_INFLUENCE_INVERT_VERTEX_GROUP`, however even those still
had one issue: if no vertexgroup was set, invert would still have been
calculated (this issue is also resolved with this PR).
Remaining modifiers that were offering influence vertexgroups (e.g.
Noise) but ignoring it now work correctly.
NOTE: there are still modifiers handling influence vertexgroups outside
of `greasepencil::get_influence_vertex_weights`:
- Armature (has own code for this in
`BKE_armature_deform_coords_with_curves`)
- Shrinkwrap (has own code for this in `shrinkwrapParams_deform`)
- Thickness (this rather special behavior is untouched)
Pull Request: https://projects.blender.org/blender/blender/pulls/133426
