Previously we were using a bespoke hodgepodge of
`Action::is_action_legacy()` and `Action::is_action_layered()`,
sometimes in combination with checking for the Baklava feature flag,
when what we really meant is "Should this action be treated as legacy
or not?"
This commit changes the places where that's semantically what we meant
to use `action_treat_as_legacy()`. Some of those places were already
correct, using a compound conditional, but some of them weren't, and
thus were not always branching correctly. For those latter cases,
this commit is a bug fix.
Importantly, not all uses of bare `Action::is_action_legacy()` or
`Action::is_action_layered()` are semantically incorrect: there are many
places where that is the right thing to do. This commit takes care not
to touch those places.
Pull Request: https://projects.blender.org/blender/blender/pulls/128174
The Action Constraint would only allow actions that were once assigned
to objects, i.e. with `action->idroot == ID_OB`. This did not take into
account the equally valid `0` case, which is what indicates that this
Action has never been assigned to anything yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/128072
Replace those calls to `BKE_fcurve_find()` that are searching in the
curves of an Action with their corresponding call in `animrig`:
- `animrig::fcurve_find_in_action()` when it should really search
through the entire Action,
- `animrig::fcurve_find_in_action_slot()` when only the F-Curves for a
specific slot should be searched, or
- `animrig::fcurve_find_in_assigned_slot()` same as above, searching
through the action slot that is assigned to the given ADT.
This also makes `animrig::fcurve_find_in_action()` compatible with both
layered and legacy Actions.
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
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
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
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
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
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
This significantly simplifies memory management, mostly by avoiding
the need to free the memory manually. It may also improve performance,
since std::string has an inline buffer that can prevent heap
allocations and it stores the size.
Pull Request: https://projects.blender.org/blender/blender/pulls/117695
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
No functional changes.
Move the function ED_id_action_ensure to animrig,
and rename it to `id_action_ensure`.
This is in order to reduce references from animrig
to the editor code.
Pull Request: https://projects.blender.org/blender/blender/pulls/116101
No functional changes.
Moving the following functions
`action_fcurve_ensure` and
`action_fcurve_find`
from
`ANIM_fcurve.hh`/`fcurve.cc`
to
`ANIM_action.hh`/`action.cc`
This is an effort to ensure that the fcurve files don't need to know
about the container they are stored in so we can swap out
the container more easily.
Pull Request: https://projects.blender.org/blender/blender/pulls/114575
No functional changes.
Since the following functions are now in a C++ namespace, their prefix can be removed:
* ANIM_setting_get_rna_values -> get_rna_values
* ED_action_fcurve_find -> action_fcurve_find
* ED_action_fcurve_ensure -> action_fcurve_ensure
Pull Request: https://projects.blender.org/blender/blender/pulls/114450
Rename the `bPoseChannel::flag` `PCHAN_HAS_TARGET` to `PCHAN_HAS_NO_TARGET`
as that is actually the meaning of the flag (in the majority of the code).
Since the flag was so confusingly named, there were some mixups in the
armature overlay drawing code as well, which have been fixed now too.
When removing all constraints from pose bones, just reset the `constflag`
field to `0`, instead of clearing out specific flags. It was already
missing a flag that should have been cleared.
Effectively no functional changes, just a nice cleanup.
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
This was noted in code comments and checked in Python documentation
generation but not at build time.
Since these enums are identifiers that end up included in various places
enforce the `rna_enum_*_items` convention which was noted as
the convention but not followed strictly.
Partially reverts [0], avoids having to deal with multiple prefix types.
[0]: 3ea7117ed1
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
This moves the following `editors/*` directories to C++:
- animation, armature, lattice, mesh, metaball, object, scene.
Much of the changes in this commit (inserting casts in particular)
was automated. Further changes like switching to functional style
casts can be done separately by existing automated scripts.
See #103343
Pull Request: https://projects.blender.org/blender/blender/pulls/109715
