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.
Pull Request: https://projects.blender.org/blender/blender/pulls/136116
In Grease Pencil length modifier, if a stroke is not filtered, it
may not have a valid point count/offset. This fix ensures that we
get valid point count by copying it beforehand.
Pull Request: https://projects.blender.org/blender/blender/pulls/135733
Previously in 43fde8c39c the point span
for calling `extend_curves_straight` was set to a fixed `{1}` with only
1 element, this causes index access to go out of range, which is the
cause of crash #135586. However there are some other issues within the
code path, mainly:
- The meaning of `start/end_points` are unclear
- Behaviour of extending a 2-point stroke is undefined
This PR clarifies these by adding some comments and change a bit of the
logic in the code so it's more understandable.
Pull Request: https://projects.blender.org/blender/blender/pulls/135608
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
Adds a mode option to the node to choose between the existing
behavior and new behavior that converts each face to a cyclic curve.
Generally this is much faster than the existing mode because it's
easy to parallelize and because curve offsets and face and corner
attributes can be implicitly shared to avoid copies.
Resolves#134671.
Pull Request: https://projects.blender.org/blender/blender/pulls/134773
Layer had their opacity reset whenever a modifier was applied.
This was due to the property not being transferred when a new GreasePencil
object was created in `geometry::merge_layers` function. This PR makes sure
to transfer the Layer opacity (similar to other layer properties).
Pull Request: https://projects.blender.org/blender/blender/pulls/135006
This was partially fixed in ef844bad but left some unhandled corner cases with
uninitialized memory.
The core problem is that the `dst_curve_mask` used by the interpolation
functions can contain indices that don't actually exist in either the "from" or
"to" source drawings. Specifically when the "from" drawing has more curves, the
indices are still used but the supplemental `to_curve_indices` array contains
`-1` entries, indicating that only the "from" curve should be used.
The main copy code for positions takes this into account, but the generic copy
of attributes below that does not! It passes the `dst_curve_mask` straight into
the `array_utils` functions and that causes crashes. The original fix in
ef844bad was to clamp the size of the index mask, but the way this was done
could lead to empty index masks, leaving attribute values uninitialized.
The correct solution is to use index masks that exclude invalid entries for the
respective source curves. The new masks are non-overlapping, so the full set of
destination curves can be filled by combining these masks.
Pull Request: https://projects.blender.org/blender/blender/pulls/134865
Though "Point Cloud" written as two words is technically correct and should be used in the UI, as one word it's typically easier to write and parse when reading. We had a mix of both before this patch, so better to unify this as well.
This commit also renames the editor/intern/ files to remove pointcloud_ prefix.
point_cloud was only preserved on the user facing strings:
* is_type_point_cloud
* use_new_point_cloud_type
Pull Request: https://projects.blender.org/blender/blender/pulls/134803
Use the existing "remove_points_and_split" utility added
for grease pencil to implement the operator for the curves
object type. The whole structure is similar to the recently
added point cloud separate operator (4cd3540579).
Pull Request: https://projects.blender.org/blender/blender/pulls/134763
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
The issue is that the existing curves did not have an explicitly set radius.
When adding new curves with an explicit radius, the radius of the old curves was
initialized to 0 and thus becoming invisible. This patch changes it so that all
the existing curves do get a default radius. The `radius_for_write` methods is
currently only used in places that overwrite the entire array, so adding the
default there shouldn't affect anything unintentionally.
Pull Request: https://projects.blender.org/blender/blender/pulls/134445
Collapsing curves to a single point when just resampling is unexpected. This
patch changes it so that non-zero-length curves keep at least one segment.
The fix is fairly straight forward, but a bunch of additional code is added to
support the legacy option to avoid breaking backward compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/133659
Selection mask is included in the stroke interpolation tool in
297b97f2df, however sometimes there will
be mismatches for when start/end curve count isn't the same. This fix
ensures that the interpolation operator only works on the max amount of
curves that can fit in both start and end side of the interpolation.
Pull Request: https://projects.blender.org/blender/blender/pulls/134484
Previously, there was a `StringRef.copy` method which would copy the string into
the given buffer. However, it was not defined for the case when the buffer was
too small. It moved the responsibility of making sure the buffer is large enough
to the caller.
Unfortunately, in practice that easily hides bugs in builds without asserts
which don't come up in testing much. Now, the method is replaced with
`StringRef.copy_utf8_truncated` which has much more well defined semantics and
also makes sure that the string remains valid utf-8.
This also renames `unsafe_copy` to `copy_unsafe` to make the naming more similar
to `copy_utf8_truncated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133677
The interpolate tool was using a linear re-sampling of the curves, which changes
non-uniform point distributions can causes unexpected shifts in points along the
curve, even very close to an input stroke (mix factor ~0 or ~1).
This patch adds an alternative interpolation function with explicit segment
indices and fractions, which can then be computed by the interpolation tool.
The point segment factors are chosen such that each point of the input strokes
has an exact matching point in the interpolation. When the factor is close to
0 or 1 the shape of the curve thus matches the respective input exactly.
This approach is more similar to what GPv2 did, except instead of sub-dividing
each segment it simply generates a _local_ uniform sample to fit more points
into the same segment. These extra points are colinear at the extremes of the
mix factor range, so the curve matches the input curves visually.
Pull Request: https://projects.blender.org/blender/blender/pulls/130594
The hardcoded value doesn't work well with real scale human heads for
example (was already adjusted once in a76b5d3a07).
The result for too high values is a complete "freeze" of the whole curve
(since the solution from e7606139ba has the problem that it keeps
running into max iterations of the collision solver).
As long as no better solver is implemented, it is better to have an
adjustable value (to work on differently sizes objects) to not run into
the above issue (same as the old particle hair system had) and show it
in sculptmode next to the button which enables collision.
This is done per `Curves` (same as the flag
`CV_SCULPT_COLLISION_ENABLED`), similar to symmetry settings
[alternatively, it could be part of `BrushCurvesSculptSettings` but I
think it makes more sense in Curves] and then passed on to the
`CurvesConstraintSolver`.
Includes versioning code (to set the default for old files).
Pull Request: https://projects.blender.org/blender/blender/pulls/132997
Propagating string attributes isn't supported in many places currently,
the split edges node is not an exception, so skip those attributes as
necessary.
Followup to 80f5b3ad21 which was just
plain wrong. Somehow I missed the whole point and set auto handle types
instead of aligned. In a more thorough dive into this area, there was
some weird structural decisions making things harder than they should be.
This commit slightly simplifies the way the first and last handle of a
segment are set, moving it all to happen in one place and making the
processing of the last cyclic segment a bit simpler. The resulting
handles are aligned if possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/133070
In order to copy vertex group weights when subdividing strokes the
groups (`bDeformGroup`) must be created in advance, so that the attribute
wrappers correctly write to `CD_MDEFORMVERT` layer instead of creating simple
`CD_PROP_FLOAT` layers.
In addition the subdivision function must take care to fully write the
destination arrays, since initial values must be considered uninitialized (this
is obfuscated for simple CustomData arrays but breaks with more complex
attributes that use a buffer). In order to ensure fully defined destination
buffers without additional copies, the `finish` call to attribute writers is
postponed until the unselected attribute values have also been copied from input
buffers and all the values are properly defined.
Pull Request: https://projects.blender.org/blender/blender/pulls/132854
The `smooth_curve_attribute` function smoothes individual
ranges of points that are selected within a stroke.
When smoothing a single range, the `gaussian_blur_1D` function
shouldn't treat this range as cyclic.
Instead, we check if the entire curve is selected and only use
the `cyclic` boolean in this case. For ranges, we always
treat them as non-cyclic.
Pull Request: https://projects.blender.org/blender/blender/pulls/132850
Implicit sharing dramatically reduces the cost of coping geometry
which is extremely helpful for read-only and slight modification.
But case of Sort Elements node implies a total rewrite of whole domain,
so implicit sharing only adds redundant cost for write access. This fix
uses kernel API to create domains without attributes, manually forcing
implicit sharing for offset indices and uses kernel attribute copy
functions to force sharing for all attributes when this is possible.
In all other cases new attributes are created from scratch and copied
as re-ordered only once.
In attached example file shown the difference depend on the number of
attributes on the mesh, benchmark result:
| Attributes | Before | After |
| ---------- | ------ | ----- |
| 1 | 2 ms | 1.5 ms |
| 5 | 5 ms | 4 ms |
| 10 | 9 ms | 6 ms |
| 50 | 45 ms | 30 ms |
| 100 | 89 ms | 59 ms |
Pull Request: https://projects.blender.org/blender/blender/pulls/117910
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
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Caused by 84c7684871.
Previously we could count on adding the attributes to the result mesh
not failing. Now, since the vertex group names are copied, they might
fail because a name would cause the attribute to already exist with a
float type on the point domain, which might not match the most
complex domain/type we'd use otherwise.
The fix is to only create attributes as vertex groups if the domain and
type combination from all the input meshes is correct.
Pull Request: https://projects.blender.org/blender/blender/pulls/132506
I had written a comment years ago mentioning that this behavior would be
preferrable, but I mistakenly assumed it was complicated to implement.
It turns out the sampled points subdividing a Bezier segment will have
symmetric "aligned" handle positions. Generally it's better to keep the
handles aligned where possible since the editing experience is a bit better.
In geometry nodes this shouldn't make an important difference because
the handle types are changed as necessary for in the set handle position
node.
Pull Request: https://projects.blender.org/blender/blender/pulls/132204
