Removes unused GPv2 functions in blenkernel.
Notes:
- Functions for layer masks are still in use, but annotations never
have layer masks in the first place. Would be good to remove the data
structures so we can remove the functions too.
- Some multi-frame edit functions are also still nominally used, but
multi-frame editing is not an active feature for annotations. This
should also be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/128709
This renames the mode identifiers to be consistent with e.g. the context mode identifiers and other names used for the new Grease Pencil.
For `object.mode`:
* `PAINT_GPENCIL` -> `PAINT_GREASE_PENCIL`
* `SCULPT_GPENCIL` -> `SCULPT_GREASE_PENCIL`
* `VERTEX_GPENCIL` -> `VERTEX_GREASE_PENCIL`
* `WEIGHT_GPENCIL` -> `WEIGHT_GREASE_PENCIL`
For the internal `ob->mode` flag:
* `OB_MODE_PAINT_GPENCIL_LEGACY` -> `OB_MODE_PAINT_GREASE_PENCIL`
* `OB_MODE_SCULPT_GPENCIL_LEGACY` -> `OB_MODE_SCULPT_GREASE_PENCIL`
* `OB_MODE_VERTEX_GPENCIL_LEGACY` -> `OB_MODE_VERTEX_GREASE_PENCIL`
* `OB_MODE_WEIGHT_GPENCIL_LEGACY` -> `OB_MODE_WEIGHT_GREASE_PENCIL`
Resolves#127374.
Pull Request: https://projects.blender.org/blender/blender/pulls/128604
Because we're moving to layered actions, which don't store their
fcurves in a list base, we need to update the places that assume the old
listbase-based structure.
This commit addresses the low-hanging fruit where code was previously
using the `LISTBASE_FOREACH` macro on a listbase of fcurves and it was
fairly obvious how to correctly update the code with minimal changes.
Other cases that either weren't immediately obvious or required
non-trivial code changes (or both) have been left for future PRs.
Additionally, uses of the list base that didn't use `LISTBASE_FOREACH`
were not investigated as part of this PR, whether trivial to update or
not.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/127920
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
This removes the legacy Grease Pencil modifiers from the code.
These should have already been inaccessible from the UI and hidden from
the user. The modifiers have been reimplemented for the new GPv3
data structure.
On top of the modifier code, some other related things have been
removed as well:
* Operators related to the legacy modifiers.
* Keymaps for the legacy modifier operators.
* Some bits of code that used modifier functions.
Some code has to be kept, because it is still used:
* The core line art code, which is used by the new line art modifier. It's
moved to `modifiers/lineart`.
* The DNA structs for the legacy modifiers. They are still needed for
conversion.
* A few kernel functions for the modifiers are kept (also for conversion).
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/125102
The code which is responsible for applying data from coordinate grids to
displacement grids could be run as part of modifier evaluation, hence
using the safe version of accessing mesh data was returning a nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/123907
This is an alternative fix to #123524.
This is necessary, because `sculpt_update_object` is run after
the mesh is evaluated, but before the geometry depsgraph operation
is done. Only after this depsgraph node is done, `DEG_object_geometry_is_evaluated`
will return true.
This approach of `unchecked` methods has been preferred for now
over moving the call to `BKE_sculpt_update_object_after_eval`
to a separate depsgraph node or after depsgraph evaluation.
While the evaluated result is not well defined, we expect Blender to not crash
when there are dependency cycles.
The evaluation of one object often takes the evaluated geometry of another
object into account. This works fine if the other object is already fully
evaluated. However, if there is a dependency cycle, the other object may not be
evaluated already. Currently, we have no way to check for this and were mostly
just relying on luck that the other objects geometry is in some valid state
(even if it's not the fully evaluated geometry).
This patch adds the ability to explicitly check if an objects geometry is fully
evaluated already, so that it can be accessed by other objects. If there are not
dependency cycles, this should always be true. If not, it may be false
sometimes, and in this case the other objects geometry should be ignored. The
same also applies to the object transforms and the geometry of a collection.
For that, new functions are added in `DEG_depsgraph_query.hh`. Those should be
used whenever accessing another objects or collections object during depsgraph
evaluation. More similar functions may be added in the future.
```
bool DEG_object_geometry_is_evaluated(const Object &object);
bool DEG_object_transform_is_evaluated(const Object &object);
bool DEG_collection_geometry_is_evaluated(const Collection &collection);
```
To determine if the these components are fully evaluated, a reference to the
corresponding depsgraph is needed. A possible solution to that is to pass the
depsgraph through the call stack to these functions. While possible, there are a
couple of annoyances. For one, the parameter would need to be added in many new
places. I don't have an exact number, but it's like 50 or so. Another
complication is that under some circumstances, multiple depsgraphs may have to
be passed around, for example when evaluating node tools (also see
`GeoNodesOperatorDepsgraphs`).
To simplify the patch and other code in the future, a different route is taken
where the depsgraph pointer is added to `ID_Runtime`, making it readily
accessible similar to the `ID.orig_id`. The depsgraph pointer is set in the same
place where the `orig_id` is set.
As a nice side benefit, this also improves the situation in simple cases like
having two cubes with a boolean modifier and they union each other.
Pull Request: https://projects.blender.org/blender/blender/pulls/123444
After recent commits, the .cc file is only used for actual object data
evaluation in the depsgraph, and the header is only used for the old
DerivedMesh data structure that's still being phased out.
Refactor `BKE_armature_min_max()` so that it calls `BKE_pose_minmax(ob,
use_hidden=false)`. The former took neither bone visibility nor custom
bone shapes into account when computing the bounding box. Now these two
are unified, fixing the regression.
`BKE_armature_min_max()` is now basically a thin wrapper that uses more
modern C++ types in its signature. This will be cleaned up in a
follow-up refactor commit.
Another difference is that these functions return the AABB in different
coordinate spaces (object vs. world). This isn't done entirely correctly
(just transforming the two extreme points), but in a way that is
symmetrical with `BKE_object_minmax()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/121739
This allows node groups to have a description that is shown in the add menu
or when hovering over the node header.
This new description is stored in `bNodeTree.description`. Unfortunately, it
conflicts a bit with `ID.asset_data.description`. The difference is that the latter
only exists for assets. However, it makes sense for node groups to have
descriptions even if they are not assets (just like `static` functions in C++ should
also be able to have comments). In some cases, node groups are also generated
by addons for a specific purpose. Those should still have a description without
being reusable to make it easier to understand for users.
The solution here is to use the asset description if the node group is an asset,
and to use `bNodeTree.description` otherwise. The description is synced
automatically when marking or clearing assets.
A side benefit of this solution is that appended node group assets can keep their
description, which is currently always lost.
Pull Request: https://projects.blender.org/blender/blender/pulls/121334
This makes the read and write API functions match more closely, and adds
asserts to check that the data size is as expected.
There are still a few places remaining that use BLO_read_data_address
and similar generic functions, these should eventually be replaced as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/120994
The main motivation for this is that it's part of a fix for #113377,
where I want to propagate the edit mesh pointers through copied
meshes in modifiers and geometry nodes, instead of just setting the
edit mesh pointer at the end of the modifier stack. That would have
two main benefits:
1. We avoid the need to write to the evaluated mesh, after evaluation
which means it can be shared directly among evaluated objects.
2. When an object's mesh is completely replaced by the mesh from another
object during evaluation (with the object info node), the final edit
mesh pointer will not be "wrong", allowing us to skip index-mapped
GPU data extraction.
Beyond that, using a shared pointer just makes things more automatic.
Handling of edit mesh data is already complicated enough, this way some
of the worry and complexity can be handled by RAII.
One thing to keep in mind is that the edit mesh's BMesh is still freed
manually with `EDBM_mesh_free_data` when leaving edit mode. I figured
that was a more conservative approach for now. Maybe eventually that
could be handled automatically with RAII too.
Pull Request: https://projects.blender.org/blender/blender/pulls/120276
Also access the evaluated deform mesh with a function rather than
directly from object runtime data. The goal is to make it easier to use
implicit sharing for these meshes and to improve overall const
correctness.
Store RNG on per thread data, instead of the effector itself which may
be used by multiple objects evaluated in different threads.
This has been causing the blendfile_versioning test to fail randomly.
Thanks Ray and Aras for helping track this down.
Pull Request: https://projects.blender.org/blender/blender/pulls/119967
There are still a few places that are more complicated where the replacement
to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly
`IDPropertyTemplate` usage.
Seems to work OK in basic cases, but needs more work when copying
outside of Main at least.
Note: There is no behavioral changes expected from this commit.
Note that there are at least two known usecases for this change:
* Liboverrides, as with recursive resync and proxies conversion it
often ends up creating 'virtual' linked data that does not actually
exists in the library blend files.
* Complex versionning code (`do_versions_after_setup`) when it needs
to create new IDs (currently handling linked data that way is just not
supported!).
Implements #107847.
There probably are more cases where crash will happen as it is
rooting into the issue with BKE_object_workob_calc_parent() which
is used in multiple places.
The issue is caused by the access to a runtime field of workob
outside of the BKE_object_workob_calc_parent(): the runtime field
is stack-allocated in the function, and can not be accessed outside
of the function.
The easiest way to reproduce is to use ASAN, and parent mesh to an
armature with automatic weights. Although, on macOS ASAN did not
report issues, so setting workob->runtime to nullptr at the end of
of the BKE_object_workob_calc_parent() was the easiest.
The solution is simple: make the function to return the matrix,
and take care of the working object inside of it, so all tricky
parts are hidden from the API.
The patch is targeting the main branch, as in 4.1 it is not
required to do such change because all uses of the function only
access object_to_world, which is stored in the object in 4.1.
A double-check in the what_does_obaction() might be needed as it
follows the similar pattern, but it does not seem that runtime
field of the workob is accessed in usages of the what_does_obaction().
Pull Request: https://projects.blender.org/blender/blender/pulls/118847
This rewrites the Alembic and USD data importers to work with and
output GeometrySets instead of Meshes.
The main motivation for this change is to be able to import properly
point clouds, which are currently imported as Meshes, and curves
data, which suffer from a lot of issues due to limitations of
legacy curves structures (fixed by the new curves data-block) and are
also converted to Meshes. Further, for Curves, it will allow importing
arbitrary attributes.
This patch was primarily meant for Alembic, but changes to USD import
were necessary as they share the same modifier.
For Alembic:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Points are imported as PointClouds
For USD:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Note that the current USD importer does not support loading PointClouds,
so this patch does not add support for it.
For both Alembic and USD, knots arrays are not read anymore, as the new
Curves object does not expose the ability to set them. Improvements can
be made in the future if and when example assets are provided.
This fixes at least the following:
#58704: Animated Alembic curves don't update on render
#112308: Curves have offset animations (alembic / USD)
#118261: wrong motion blur from usd in cycles and reverting to the first
frame when disabeling motion blur
Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/115623
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
This data was 'hidden' away in a util in
`lib_query.cc`, which made it hard to discover and keep up-to-date.
However, as shown by e.g. #108407, critical low-level features in ID
management code, such as remapping, now rely on this information being
valid.
Also simplify `BKE_library_id_can_use_filter_id` and
`BKE_library_id_can_use_idtype` to make them more generic, relying on
IDTypeInfo to retrieve IDtype-specific info.
No behavioral changes expected here.
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
I added a new BLO_userdef_default.h header to contain declarations of
two global variables that are still defined in C files. Use of designated
initializers for large structs make those files harder to change.
Arguably this is a better header for them anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118015
Since 1497005054, there is a new `ModifierData.persistent_uid` which
has more use cases than the old `session_uid`. This patch removes
`ModifierData.session_uid` and replaces its usages with the new `persistent_uid`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117909
This adds a new `ModifierData.persistent_uid` integer property with the following properties:
* It's unique within the object.
* Match between the original and evaluated object.
* Stable across Blender sessions.
* Stable across renames and reorderings of modifiers.
Potential use-cases:
* Everywhere where we currently use the name as identifier. For example,
`ModifierComputeContext` and `ModifierViewerPathElem`.
* Can be used as part of a key in `IDCacheKey` to support caches that stay
in-tact across undo steps.
* Can be stored in the `SpaceNode` to identify the modifier whose geometry node
tree is currently pinned (this could use the name currently, but that hasn't been
implemented yet).
This new identifier has some overlap with `ModifierData.session_uid`, but there
are some differences:
* `session_uid` is unique within the entire Blender session (except for duplicates
between the original and evaluated data blocks).
* `session_uid` is not stable across Blender sessions.
Especially due to the first difference, it's not immediately obvious that the new
`persistent_uid` can fulfill all use-cases of the existing `session_uid`. Nevertheless,
this seems likely and will be cleaned up separately.
Unfortunately, there is not a single place where modifiers are added to objects currently.
Therefore, there are quite a few places that need to ensure valid identifiers. I tried to catch
all the places, but it's hard to be sure. Therefore, I added an assert in `object_copy_data`
that checks if all identifiers are valid. This way, we should be notified relatively quickly if
issues are caused by invalid identifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/117347
This simplifies code using these functions because of RAII,
range based for loops, and the lack of output arguments.
Also pass object pointer array as a span in more cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/117482
