This fixes two issues:
* There was a crash when the new attribute name was empty.
* The attribute name was incremented (e.g. "Attribute.001") when
the old and new name were the same.
It looked up the vertex group index based on the object instead of the
actual mesh that is currently used. Since geometry nodes, the number
and order of attributes can change in arbitrary ways during evaluation.
Therefore, this index has to be looked up on the mesh which contains
the most up-to-date information.
There are probably similar issues in other modifiers. That has to be
fixed step by step. Ideally by using the attribute api directly eventually.
Calling two non-const methods on a `MutableAttributeAccessor`
at the same time in multiple threads is not safe.
While I don't know what caused the crash here exactly, I do know
that it happens while looking up the attribute for writing, which
may modify the unterlying geometry. I couldn't reproduce the
bug with a debug build or without threading.
As discussed, this only updates objects in and the world of the scene to which the view layer belongs, which also avoids the problem of not having a BMain available.
Differential Revision: https://developer.blender.org/D14740
Use the C++ API to implement more of the existing C functions.
This corrects the cases where one tries to add a builtin attribute
with the wrong domain or type on curves, though a better warning
message would be helpful in the future, and also reduces duplication
of the internal logic. Not much more is possible without changing
the interface.
Use the new attribute API to implement the attribute remove function
used by RNA, except for BMesh attributes. Currently, removing curve
attributes from the panel in the property editor does not mark the
relevant caches dirty (for example, the cache of curve type counts),
because that behavior is implemented with the new attribute API.
Also, eventually we want to merge the two APIs, and removing an
attribute is the first function that can be partially implemented
with the new API.
Differential Revision: https://developer.blender.org/D15495
Geometry nodes has added the ability to modify mesh vertex groups
during evaluation (see 3b6ee8cee7). However, the armature
modifier always uses the vertex groups from the original object.
This is wrong for the modifier stack, where each modifier is meant
to use the output of the previous.
This commit makes the armature modifier use the evaluated vertex groups
if they are available. Otherwise it uses the originals like before.
Differential Revision: https://developer.blender.org/D15515
Previously, curves sculpt tools only worked on original data. This was
very limiting, because one could effectively only sculpt the curves when
all procedural effects were turned off. This patch adds support for curves
sculpting while looking the result of procedural effects (like deformation
based on the surface mesh). This functionality is also known as "crazy space"
support in Blender.
For more details see D15407.
Differential Revision: https://developer.blender.org/D15407
The conversion from Curves to CurveEval used an incorrect type
for one of the builtin attributes. Also, an incorrect default was used
for reading the nurbs_weight attribute.
Actualy 'safe' building of the base has in view layers (as part of
`BKE_main_collection_sync_remap`) would only happen when there was
already an existing one, otherwise it was skipped, and rebuilt later
(without the support for doublons) in collection sync code.
Very odd that that error was never spotted before, issue in code has
been there for a long time already. Probably only happens in rare cases
(specific conjuction of factors during remapping of old ID into itelf
new id)?
Reported by @hjalti from Blender studio. Reproducing case:
`heist/pro/shots/050_alarm/050_0160/050_0160.anim.blend`, r1407
Code handling read/write of libraries is still particular... but trying
to call `library_runtime_reset` on a random address at readtime was an
obvious mistake I should have caught during review :(
Regression from rB7f8d05131a77.
Calling `finish` after writing to generic attributes is currently necessary for
correctness. Previously, this was easy to forget. Now there is a check for this
in debug builds.
Use the attribute API instead of the CustomData API, to correctly
handle anonymous attributes and simplify the code. One non-obvious
thing to note is that the type counts are recalculated by the "finish"
function of the `curve_type` attribute, so they don't need to be copied
explicitly. Also, the mutable attribute accessor cannot be an reference
if we want to give it an rvalue, which is convenient in this case.
The normals are transformed, but not used. It looks like this logic was
just copied from below where the mesh is transformed for creating
emitters, which do use vertex normals.
All callers passed `false` for this parameter, making it more confusing
than useful. If this functionality is needed again in the future, a separate
function should be added.
Differential Revision: https://developer.blender.org/D15401
An implementation of T73412, roughly as outlined there:
Track the names that are in use, as well as base names (before
numeric suffix) plus a bit map for each base name, indicating which
numeric suffixes are already used. This is done per-Main/Library,
per-object-type.
Timings (Windows, VS2022 Release build, AMD Ryzen 5950X):
- Scene with 10k cubes, Shift+D to duplicate them all: 8.7s -> 1.9s.
Name map memory usage for resulting 20k objects: 4.3MB.
- Importing a 2.5GB .obj file of exported Blender 3.0 splash scene
(24k objects), using the new C++ importer: 34.2s-> 22.0s. Name map
memory usage for resulting scene: 8.6MB.
- Importing Disney Moana USD scene (almost half a million objects):
56min -> 10min. Name map usage: ~100MB. Blender crashes later on
when trying to render it, in the same place in both cases, but
that's for another day.
Reviewed By: Bastien Montagne
Differential Revision: https://developer.blender.org/D14162
- The custom space target never needs B-Bone data (used by depsgraph).
- When drawing the relationship lines use the space matrix directly.
- Don't use the custom target to control the target space type dropdown.
Differential Revision: https://developer.blender.org/D9732
Add calls to a few locations that look like they may need to
initialize the Custom Space matrix, i.e. generally any place
that computes target matrices.
Differential Revision: https://developer.blender.org/D9732
Adds a new option to the 'Delete ShpaKeys' operator, which first applies
the current mix to the object data, before removing all shapekeys.
Request from @JulienKaspar from Blender studio.
Reviewed By: JulienKaspar
Differential Revision: https://developer.blender.org/D15443
This commit ports the fillet curves node to the new curves data-block,
and moves the fillet node implementation to the geometry module to help
separate the implementation from the node.
The changes are similar to the subdivide node or resample node. I've
resused common utilities where it makes sense, though some things like
the iteration over attributes can be generalized further. The node
is now multi-threaded per-curve and inside each curve, and some buffers
are reused per curve to avoid many allocations.
The code is more explicit now, and though there is more boilerplate to
pass around many spans, the more complex logic should be more readable.
Differential Revision: https://developer.blender.org/D15346
These mutable pointers present problems with ownership in relation to
proper copy-on-write for attributes. The simplest solution is to just
remove them and retrieve the layers from `CustomData` when they are
needed. This also removes the complexity and redundancy of having to
update the pointers as the curves change. A similar change will apply
to meshes and point clouds.
One downside of this change is that it makes random access with RNA
slower. However, it's simple to just use the RNA attribute API instead,
which is unaffected. In this patch I updated Cycles to do that. With
the future attribute CoW changes, this generic approach makes sense
because Cycles can just request ownership of the existing arrays.
Differential Revision: https://developer.blender.org/D15486
Previously, things like materials, symmetry, and selection options
stored on `Curves` weren't copied to the result in nodes like the
subdivide and resample nodes. Now they are, which fixes some
unexpected behavior and allows visualization of the sculpt mode
selection.
In the realize instances and join nodes the behavior is the same as
for meshes, the parameters are taken from the first (top) input.
I also refactored some functions to return a `CurvesGeometry` by-value,
which makes it the responsibility of the node to copy the parameters.
That should make the algorithms more reusable in other situations.
Differential Revision: https://developer.blender.org/D15408
openSubdiv_init() would detect available evaluators before any OpenGL context
exists, causing a crash with libepoxy. This test however is redundant as we
already check the requirements on the Blender side through the GPU API.
To simplify things, completely remove the device detection in the opensubdiv
module and reduce the evaluators to just CPU and GPU. The plan here is to move
to the GPU module abstraction over OpenGL/Metal/Vulkan and so all these
different backends no longer make sense.
This also removes the user preference for OpenSubdiv compute device, which was
not used for the new GPU subdivision implementation.
Ref D15291
Differential Revision: https://developer.blender.org/D15470
An increased number of vertices is not a stopper for the surface
deform modifier anymore. It might still be useful to expose the
message in the UI, but printing error message to the console on
every modifier evaluation makes real errors to become almost
invisible.
Differential Revision: https://developer.blender.org/D15468
The outliner would tagg all existing local IDs (for remap from linked
reference data to newly created overrides) when creating a new override.
This would become critical issue in case there is several existing
copies of the same override hierarchy (leading to several hierarchies
using the same override).
Further more, BKE override creation code would not systematically
properly remapp linked usages to new overrides one whithin the affected
override hierarchy, leading to potential undesired remaining usages of
linked data.
This is useful when using an armature as a camera rig, to avoid creating and
targetting an empty object.
Differential Revision: https://developer.blender.org/D7012
Use const pointers to ImageSaveOptions and ImageFormatData for API
parameters where appropriate.
Differential Revision: https://developer.blender.org/D15400
As part of a larger change (https://developer.blender.org/D14162),
adding more test coverage for existing functionality separately.
New tests:
- ids_sorted_by_default
- ids_sorted_by_default_with_libraries
- name_too_long_handling
- create_equivalent_numeric_suffixes
- zero_suffix_is_never_assigned
- remove_after_dup_get_original_name
- name_number_suffix_assignment
- renames_with_duplicates
- names_are_unique_per_id_type