This improves performance e.g. when creating an integer attribute
based on an index field. For 4 million vertices, I measured a speedup
from 3.5 ms to 1.2 ms.
Add the ability to get/set the selected text.
**Calling the new methods:**
- `bpy.data.texts["Text"].region_as_string()`
- `bpy.data.texts["Text"].region_from_string("Replacement")`
Expose the "Connected" mode from the weld modifier in the
"Merge by Distance" geometry node. This method only merges
vertices along existing edges, but it can be much faster
because it doesn't have to build a KD Tree of all selected
points.
Differential Revision: https://developer.blender.org/D14321
Change the modifier name in the modifier stack to "Curvature 3D"
to be consistent with the modifier name in the drop-down.
Differential Revision: https://developer.blender.org/D14476
If all islands had a size of zero, a division by zero would occur in
`GEO_uv_parametrizer_pack`, causing the UV coordinates to be set to
NaN. An alternative approach would be to skip packing islands with a
zero size, but If UV coordinates are for example outside the 0-1 range,
it's better if they get moved into that range.
Differential Revision: https://developer.blender.org/D14522
Set the curve resolution to Bezier and Nurbs curves when converting
data using `curves_to_curve_eval`. This was missed in 9ec12c26f1.
Differential Revision: https://developer.blender.org/D14577
Add "for_write" on function names that retrieve mutable data arrays.
Though this makes function names longer, it's likely worth it because
it allows more easily using the const functions in a non-const context,
and reduces cases of mistakenly retrieving with edit access.
In the long term, this situation might change more if we implement
attributes storage that is accessible directly on `CurvesGeometry`
without duplicating the attribute API on geometry components,
which is currently the rough plan.
Differential Revision: https://developer.blender.org/D14562
Change uses of "Hair" in Render Settings UI in the property editor
and the "Hair Info" node to use the "Curves" name to reflect the
design described in T95355, where hair is just a use case of a more
general curves data type.
While these settings still affect the particle hair system,
the idea is that if we have to choose one naming scheme to align
with, we should choose the option that aligns with future plans
and current development efforts, especially since the particle
system is considered a legacy feature.
A few notes:
- "Principled Hair BSDF" is not affected since it's meant for hair.
- Python API property identifiers are not affected.
Differential Revision: https://developer.blender.org/D14573
The last length value was not initialized, and all length values were
moved one position towards the front of each curve incorrectly.
Also fix an assert when a curve only had a single point.
When showing an action data-block added to a library overridden object
in the Graph Editor, the visibility toggles would be disabled.
Toggling the visibility should be possible still and works with the
shortcuts, just the button was incorrectly disabled.
Also added the usual disabled hint for the tooltip.
Differential Revision: https://developer.blender.org/D14568
Reviewed by: Bastien Montagne
Original rework of caches during undo/redo (see D8183) had a very bad
flaw hidden in it: using the key of a ghash as source of data.
While this was effectively working then (cache pointer itself being part
of the key, and said cache pointers not being cleared on file write),
this is a general very bad way to do things.
Now that cache pointers are more and more cleared on file write (as part
of clearing runtime-data to reduce false-positives when checking if an
ID has changed or not), this has to be fixed properly by:
* Not storing the cache pointer itself in the IDCacheKey.
* In undo context, in readfile code trying to preserve caches, store the
cache pointers as values of the mapping, together with the usages counter
The first change potentially affects all usages of
`BKE_idtype_id_foreach_cache`, but in practice this code is only used by
memfile reading code (i.e. undo) currently.
Related to T97015.
Reviewed By: brecht
Maniphest Tasks: T97015
Differential Revision: https://developer.blender.org/D14559
Python exceptions are now shown in the info editor,
this also resolves an old bug where errors were printed twice.
This was originally based on D9752 by @ShadowChaser although many
changes have been made from the original patch.
Details:
- BPy_errors_to_report no longer prints additional output.
- BKE_report_print_test was added so it's possible to check if calling
BKE_report also printed to the stdout.
- Callers to BPy_errors_to_report are responsible for ensuring output
is printed to the stdout/stderr.
- Python exceptions no longer add a trailing newline,
needed to avoid blank-space when displayed in the info-editor.
The `BVHCacheType bvh_cache_type` parameter defines specific
`BVHTrees` that cannot be customized.
So it doesn't make sense to pass this value to any
`*bvhtree_from_[...]_ex` function as the `BVHTrees` created in these
cases are custom and cannot be saved in the cache.
This also resulted in a nice cleanup in the code.
Differential Revision: https://developer.blender.org/D14479
In summary the changes are:
- Merge all `bvhtree_from_mesh_*.*_setup_data` in a single utility
- Create `bvhtree_from_editmesh_setup_data`
- Setup data only once in `BKE_bvhtree_from_mesh_get` and `BKE_bvhtree_from_editmesh_get`
Also the behavior of `BKE_bvhtree_from_mesh_get` and
`BKE_bvhtree_from_editmesh_get` changed a bit:
- If a null tree is cached, don't set the `data` to zero. This tree is not an error and the others data can still be used.
- If a null tree is returned, don't set the `data` to zero. Matches the previous change.
Differential Revision: https://developer.blender.org/D14549
color attribute system.
This commit removes sculpt colors from experimental
status and unifies it with vertex colors. It
introduces the concept of "color attributes", which
are any attributes that represents colors. Color
attributes can be represented with byte or floating-point
numbers and can be stored in either vertices or
face corners.
Color attributes share a common namespace
(so you can no longer have a floating-point
sculpt color attribute and a byte vertex color
attribute with the same name).
Note: this commit does not include vertex paint mode,
which is a separate patch, see:
https://developer.blender.org/D14179
Differential Revision: https://developer.blender.org/D12587
Ref D12587
This adds missing cases to detect edit mode for Curves objects.
Unlike other object types, Curves do not have specific edit data,
rather we edit the original data directly, and rely on `Object.mode`.
For this, `BKE_object_data_is_in_editmode` had to be modified to
take a pointer to the object. This affects two places: the outliner
and the dependency graph. For the former place, the object pointer
is readily available, and we can use it. For the latter, the object
pointer is not available, however since it is used to update edit
mode pointers, and since Curves do not have such data, we can
safely pass null to the function here.
This also fixes the assertion failure that happens when closing a file
in edit mode.
Differential Revision: https://developer.blender.org/D14330
Instead of using `CurveEval` to draw the curve wire edges, use
the new `Curves` data-block, which is already built as part of
an object's evaluated geometry set whenever there is a
`CurveComponent`.
This means that we can remove `Curve`'s temporary ownership
of `CurveEval` for drawing (added in 9ec12c26f1),
which caused a memory leak as described in T96498.
In my testing this improved performance by around 1.5x during
viewport playback, back to the performance of 3.1 before the
curve data structure transition started.
The next step of using the GPU to do the final curve evaluation
for the viewport is described in T96455, but is unrelated.
Differential Revision: https://developer.blender.org/D14551
This commit furthers some of the changes that were started in
rBb9febb54a492 and subsequent commits by changing the way surface
objects are presented to render engines and other users of evaluated
objects in the same way. Instead of presenting evaluated surface objects
as an `OB_SURF` object with an evaluated mesh, `OB_SURF` objects
can now have an evaluated geometry set, which uses the same system
as other object types to deal with multi-type evaluated data.
This clarification makes it more obvious that lots of code that dealt
with the `DispList` type isn't used. It wasn't before either, now it's
just *by design*. Over 1100 lines can be removed. The legacy curve
draw cache code is much simpler now too. The idea behind the further
removal of `DispList` is that it's better to focus optimization efforts
on a single mesh data structure.
One expected functional change is that the evaluated mesh from surface
objects can now be used in geometry nodes with the object info node.
Cycles and the OBJ IO tests had to be tweaked to avoid using evaluated
surface objects instead of the newly exposed mesh objects.
Differential Revision: https://developer.blender.org/D14550
This adds a new Grow/Shrink brush which is similar to the Length
brush in the old hair system.
* It's possible to switch between growing and shrinking by hold
down ctrl and/or by changing the direction enum.
* 3d brush is supported.
* Different brush falloffs are supported.
* Supports scaling curves uniformly or shrinking/extrapolating
them. Extrapolation is linear only in this patch.
* A minimum length settings helps to avoid creating zero-sized curves.
Differential Revision: https://developer.blender.org/D14474
Those geometry types are expected to behave the same as e.g. mesh
with respect to data copying. The fact that this was not enabled
already was an oversight in the initial commit that added these types.
Differential Revision: https://developer.blender.org/D14554
Regression in [0] which missed excluding FRAME_CHANGE from
deg_recalc_flags_for_legacy_zero causing all
DEG_id_tag_update(&scene->id, 0) calls to re-calculate animation data.
When this tagging was done in the RNA update function, changing
key-framed values in the UI would be immediate reset to their
keyed-values.
Thanks to Philipp Oeser for finding the root cause.
[0]: 35aedd87e7
