Implements setting the armature parent and generating
vertex groups for the bones in the armature.
Note: This does not implement the `Envelope` or `Automatic Weights` options.
Pull Request: https://projects.blender.org/blender/blender/pulls/127515
The second time the operator ran without a depdency graph
evaluation happening for another reason, the object's evaluated
transform matrices weren't calculated. The fix is to make sure the
depsgraph is evaluated when the operator is executed.
This fixes two things:
* Pass the evaluated object into `BKE_object_as_kdtree` instead of the original
one. `BKE_object_as_kdtree` uses functions on the object which are only
expected to be executed on evaluated objects, such as
`BKE_object_get_mesh_deform_eval`. Note that this is the only place where
`BKE_object_as_kdtree` is used.
* Tag depsgraph at the end of setting parent. This way,
`BKE_object_get_evaluated_mesh` will return the correct mesh instead of null.
It was returning null because it the object is not in a fully evaluated state
if it just has been tagged as requiring an update.
Pull Request: https://projects.blender.org/blender/blender/pulls/126086
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
Both the Follow Curve constraint and parenting with the follow curve option
require a property on the Curve ID to be animated if the user wants the
follower object to animate along the curve. However, the fcurve for this
was always getting created as a legacy action fcurve, regardless of whether
the action was actually legacy or not. If the action was layered, this
resulted in the follower object not animating along the path.
The underlying issue was that the code that created the fcurve was using
`action_fcurve_ensure()`, which hadn't yet been updated to work correctly with
layered actions, and thus the fcurve was created as if the action was legacy.
This commit fixes that by updating `action_fcurve_ensure()` to work with
Baklava phase-1 layered actions in limited circumstances, and also
ensuring that the follow curve code passes an appropriate ID RNA pointer
(required to find/create an appropriate Slot).
Pull Request: https://projects.blender.org/blender/blender/pulls/124353
When linking object data between two armatures the selection would not work
on the armature which got the new armature data assigned.
That is until a bone is added or something else is done to the armature that triggers a rebuild.
The fix is to trigger the rebuild in the link operator.
This only fixes this particular issue, the issue of bone selection sync between armature instances
is not fixed, but tracked in this report #117892
Pull Request: https://projects.blender.org/blender/blender/pulls/123743
This is a follow up to #123022 to clean up the resultant verbose parameter
passing. We add a new struct `FCurveDescriptor` that contains the parameters
needed for either looking up or creating an fcurve, and that in turn is passed
down the keyframing call chains where fcurve lookup/creation needs to be done.
Pull Request: https://projects.blender.org/blender/blender/pulls/123486
Fixes#107880.
When making a linked asset local, you typically wouldn't want this new
data-block to suddenly be part of the asset libraries this file is in. To the
user it seems like making such a data-block local also implicitly makes it an
asset. Appending an asset already handles this, and clears the asset data by
default.
This patch modifies the `bpy.types.ID.make_local()` method, as well as all
internal calls to the make local functions, so that asset data is cleared by
default. The Python method has a new `clear_asset_data` parameter (optional,
true by default). Maybe this should not be optional.
Pull Request: https://projects.blender.org/blender/blender/pulls/110197
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
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
Removal of confirmation dialogs for the following five operators. For
each of these the UI module felt that they are all either very explicit
actions and/or are easily undone.
* ARMATURE_OT_separate (Move selected bones to a separate armature)
* CURVE_OT_separate - “Move selected points to a new object”
* OBJECT_OT_vertex_parent_set (Parent selected ob to selected vertices)
* OBJECT_OT_parent_no_inverse_set (Make Parent w/o inverse correction)
* FILE_OT_directory_new - (Create New Directory)
Pull Request: https://projects.blender.org/blender/blender/pulls/120036
Move the public functions from the editors/object (`ED_object.hh`)
header to the `blender::ed::object` namespace, and move all of the
implementation files to the namespace too. This provides better code
completion, makes it easier to use other C++ code, removes unnecessary
redundancy and verbosity from local uses of public functions, and more
cleanly separates different modules.
See the diff in `ED_object.hh` for the main renaming changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119947
Small operator confirmations get separate confirm and cancel buttons,
better descriptions and configurable confirm button text. But still
popup at cursor location and can be cancelled with mouse movement.
Pull Request: https://projects.blender.org/blender/blender/pulls/118346
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
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
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
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
In particular, while Object (un)linking was already tagged in relevant
BKE code, collection (un)linking was not in several cases.
This was (partially) done by user code, though almost never for the
whole hierarchy of parents.
Technically, the tag is done as part of
`collection_object_cache_free_parent_recursive`/`collection_object_cache_free`,
since currently clearing this cache is done everytime to collection
hierarchy or their content is modified.
It also removes `collection_tag_update_parent_recursive`, which was
already doing something similar, but was only called from code
adding/removing objects to collections, and was walking the same parent
hierarchy as `collection_object_cache_free_parent_recursive`.
This commit implements the decision made in #116601, to tag modified
data as close as possible from the code modifying it.
---------------------
This has an impact on deg tagging, which takes over twice as much cycles
with this commit compared to previous code when opening a Pets production
file with several liboverrides (`deggraph_id_tag_update_single_flag` goes
from less than 0.03% to over 0.06%).
The overhead remains extremely low though, and is totally unmeasurable in
global execution timing. Timing of the liboverride processing on opening
the production file also did not show any measurable differences.
Pull Request: https://projects.blender.org/blender/blender/pulls/116986
