What is (or isnt) supported here depends on object types (but we were
getting most of the options for all object types):
| **obtype** | **supports Armature modifier** | **supports vertex groups** | **supports envelopes** | **supports automatic weights** |
| -- | -- | -- | -- | -- |
| OB_MESH | yes | yes | yes | yes |
| OB_CURVES_LEGACY | yes | no | yes | no |
| OB_CURVES | no | no | no | no |
| OB_SURF | yes | no | yes | no |
| OB_MBALL | no | no | no | no |
| OB_FONT | yes | no | yes | no |
| OB_VOLUME | no | no | no | no |
| OB_GREASE_PENCIL | yes | yes | yes | yes |
| OB_LATTICE | yes | yes (broken though) | yes | no |
| OB_EMPTY | no | no | no | no |
| OB_SPEAKER | no | no | no | no |
| OB_LIGHTPROBE | no | no | no | no |
| OB_LAMP | no | no | no | no |
| OB_ARMATURE | no | no | no | no |
| OB_POINTCLOUD | no | no | no | no |
This PR does two things:
- tidy up the popup menu we get for parenting (removing non-funtional
options)
- enable "With Empty Groups" for lattices (no reason why this should not
work)
What this PR does not touch:
- the poll function for parenting (since this acts on selected objects,
checking all of them can be a costly operation which should not be part
of a poll function)
Pull Request: https://projects.blender.org/blender/blender/pulls/134037
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
These are converted on startup to the new type. There are still
some references left, mostly where it looked like there still needs
to be changes to properly deal with the new object type.
The `fmt::format` can process the format string at compile time. Currently, we
don't seem to be using that as we don't use `FMT_STRING`. Starting with C++20,
that will be the default though, and one has to explicitly opt out in places
where the string is not known at compile time using `fmt::runtime(...)`.
Currently, our code does not compile as C++20 because of that. Unfortunately, we
have many places with runtime format strings, because of i18n.
Pull Request: https://projects.blender.org/blender/blender/pulls/130392
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
