Move `CD_CUSTOMLOOPNORMAL` to the newly added
`CD_PROP_INT16_2D` generic attribute type. This is similar to
previous commits moving specific custom data types.
The attribute name is `custom_normal`. When the attribute with
that name is on the face corner domain, the code will interpret it
as stored in the existing deformation-invariant spherical coordinate
space.
The API remains the same, with the additional opportunity to edit
custom normal data as an attribute directly (which admittedly is fairly
unintuitive currently).
See #130484.
Pull Request: https://projects.blender.org/blender/blender/pulls/130689
We've had a bunch of inconsistency between `channel_bag` and `channelbag` in the
code base. After discussion with @dr.sybren, we decided to standardize on
`channelbag` and also rename the camelcase `ChannelBag` to `Channelbag` to be
consistent with that.
This PR implements those changes.
Note that the reason we standardized on `channelbag` rather than `channel_bag`
is because it makes things clearer when stringing multiple terms together in
type and function names. For example, in `channelbag_fcurves_move()` it makes
it clear that `channelbag` describes one thing, rather than `channel` and `bag`
being two separate things.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/130988
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.
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
For C/C++ doc-strings should be located in headers,
move function comments into the headers, in some cases merging
with existing doc-strings, in other cases, moving implementation
notes into the function body.
This commit takes the 'Slotted Actions' out of the experimental phase.
As a result:
- All newly created Actions will be slotted Actions.
- Legacy Actions loaded from disk will be versioned to slotted Actions.
- The new Python API for slots, layers, strips, and channel bags is
available.
- The legacy Python API for accessing F-Curves and Action Groups is
still available, and will operate on the F-Curves/Groups for the first
slot only.
- Creating an Action by keying (via the UI, operators, or the
`rna_struct.keyframe_insert` function) will try and share Actions
between related data-blocks. See !126655 for more info about this.
- Assigning an Action to a data-block will auto-assign a suitable Action
Slot. The logic for this is described below. However, There are cases
where this does _not_ automatically assign a slot, and thus the Action
will effectively _not_ animate the data-block. Effort has been spent
to make Action selection work both reliably for Blender users as well
as keep the behaviour the same for Python scripts. Where these two
goals did not converge, reliability and understandability for users
was prioritised.
Auto-selection of the Action Slot upon assigning the Action works as
follows. The first rule to find a slot wins.
1. The data-block remembers the slot name that was last assigned. If the
newly assigned Action has a slot with that name, it is chosen.
2. If the Action has a slot with the same name as the data-block, it is
chosen.
3. If the Action has only one slot, and it has never been assigned to
anything, it is chosen.
4. If the Action is assigned to an NLA strip or an Action constraint,
and the Action has a single slot, and that slot has a suitable ID
type, it is chosen.
This last step is what I was referring to with "Where these two goals
did not converge, reliability and understandability for users was
prioritised." For regular Action assignments (like via the Action
selectors in the Properties editor) this rule doesn't apply, even though
with legacy Actions the final state ("it is animated by this Action")
differs from the final state with slotted Actions ("it has no slot so is
not animated"). This is done to support the following workflow:
- Create an Action by animating Cube.
- In order to animate Suzanne with that same Action, assign the Action
to Suzanne.
- Start keying Suzanne. This auto-creates and auto-assigns a new slot
for Suzanne.
If rule 4. above would apply in this case, the 2nd step would
automatically select the Cube slot for Suzanne as well, which would
immediately overwrite Suzanne's properties with the Cube animation.
Technically, this commit:
- removes the `WITH_ANIM_BAKLAVA` build flag,
- removes the `use_animation_baklava` experimental flag in preferences,
- updates the code to properly deal with the fact that empty Actions are
now always considered slotted/layered Actions (instead of that relying
on the user preference).
Note that 'slotted Actions' and 'layered Actions' are the exact same
thing, just focusing on different aspects (slot & layers) of the new
data model.
The "Baklava phase 1" assumptions are still asserted. This means that:
- an Action can have zero or one layer,
- that layer can have zero or one strip,
- that strip must be of type 'keyframe' and be infinite with zero
offset.
The code to handle legacy Actions is NOT removed in this commit. It will
be removed later. For now it's likely better to keep it around as
reference to the old behaviour in order to aid in some inevitable
bugfixing.
Ref: #120406
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
It is possible to have IK solver without actual bones. There was a relation
created for this case, but it was originating from a wrong operation: it
was possible to run into situation when init is not yet done, but cleanup
is already run.
Fix the relation which ensures the order to go from IK initialization and
not the pose initialization. This should ensure proper cleanup order.
There is a relation from pose initialization to IK initialization so this
change should not cause any missing relations.
This should fix the intermittent failure of blendfile_versioning_1_over_8.
Pull Request: https://projects.blender.org/blender/blender/pulls/128267
This updates the layered action data model to store strip data differently. Specifically:
- `Strip` is now just a single, POD type that only stores the data common to all
strips, such as start/end frames.
- The data that might be of a completely different nature between strips (e.g.
keyframe data vs modifier data) is now stored in arrays on the action itself.
- `Strip`s indicate their type with an enum, and specify their data with an
index into the array on the action that stores data for that type.
This approach requires a little more data juggling, but has the advantage of
making `Strip`s themselves super simple POD types, and also opening the door to
trivial strip instancing later on: instances are just strips that point at the
same data.
The intention is that the RNA API remains the same: from RNA's perspective there
is no data storage separate from the strips, and a strip's data is presented as
fields and methods directly on the strip itself. Different strip types will be
presented as different subtypes of `ActionStrip`, each with their own fields and
methods specific to their underlying data's type. However, this PR doesn't
implement that sub-typing, leaving it for a future PR. It does, however, put the
fields and methods of the one strip type we have so far directly on the strip,
which avoids changing the APIs we have so far.
This PR implements the bulk of this new approach, and everything should be
functional and working correctly. However, there are two TODO items left over
that will be implemented in forthcoming PRs:
- Type refinement in the RNA api. This PR actually removes the existing type
refinement code that was implemented in terms of the inheritance tree of the
actual C++ types, and this will need to be reimplemented in terms of the new
data model. The RNA API still works without the type refinement since there
are only keyframe strips right now, but it will be needed in preparation for
more strip types down the road.
- Strip data deletion. This PR only deletes data from the strip data arrays when
the whole action is deleted, and otherwise just accumulates strip data as more
and more strips are added, never removing the data when the corresponding
strips get removed. That's fine in the short term, especially since we only
support single strips right now. But it does need to be implemented in
preparation for proper layered actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/126559
Add support for slotted Actions to the NLA evaluation code.
This also affects the pose library code and the Action Constraint. These
both share some Action evaluation logic with the NLA. They now
explicitly looks at only the first Action slot. The Action Constraint will
have to be updated to have an explicit slot selector, but that's for another
commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/127425
The issue is due to a dependency cycle which leads to access of data
which is not ready yet.
The dependency cycle was introduced in ada367a0e9.
This change makes it so there is no dependency cycle in the setup from
the report by re-routing dependencies a bit: the light linking now
bypasses the geometry component and is only wired to an operation
related on instancing collection (but not use by a boolean modifier).
Pull Request: https://projects.blender.org/blender/blender/pulls/127143
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
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
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
Point caches can be part of modifiers, in which case changes to the
input geometry should reset the cache. This worked when the input data
is the initial object data, but does not take the modifier stack into
account. A preceding modifier could update based on some dependency
and the point cache would be none the wiser.
The `POINT_CACHE_RESET` depsgraph node now gets additional dependencies
if it's in a modifier with a predecessor.
Caveat: all caches are represented by a single node currently. That
means an indirect change to a modifier will reset all caches of that
object.
Fixes#74523
Pull Request: https://projects.blender.org/blender/blender/pulls/124247
Rename "Animation data-block" to "Action" or "Layered Action", where
appropriate. Some uses of the term actually refer to the `AnimData`
struct, in which case they were left as-is.
No real functional changes, just changing some messages & descriptions.
Pull Request: https://projects.blender.org/blender/blender/pulls/124170
Rename 'Binding' to 'Slot'. The old term was causing all kind of
confusion, and 'slot' was considered to be a better term for the
intended functionality.
This commit breaks existing blend files that were using the new layered
Action for their animation. The animation data will be lost due to the
rename, as there is no versioning code or DNA renaming logic. At this
time the new system is still marked as experimental, so shouldn't be
used for anything serious anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/124170
The idea is to skip building data-blocks referenced by ID
properties for dependency graphs used by render pipeline and
compositor preview. Those graphs do not use handlers, so it
is not required to have custom references to data-blocks
evaluated.
This solves an initial hicckup and memory usage with file
from #121188 when doing compositor. It also reduces the time
until first pixel when hitting F12 on that file.
Pull Request: https://projects.blender.org/blender/blender/pulls/123439
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 new/experimental, layered `Animation` data-block is merged with the
existing `bAction` data-block.
The `Animation` data-block is considerably newer than `bAction`, so the
supporting code that was written for it is also more modern. When moving
that code into `bAction`, I chose to keep the modernity where possible,
and thus some of the old code has been updated as well. Things like
preferring references over pointers.
The `Animation` data-block is now gone from DNA, the main database, etc.
As this was still an experimental feature, there is no versioning code
to convert any of that to Actions.
The DNA struct `bAction` now has a C++ wrapper `animrig::Action`, that
can be obtained via `some_action->wrap()`.
`animrig::Action` has functions `is_empty()`, `is_action_legacy()`, and
`is_action_layered()`. They **all** return `true` when the Action is
empty, as in that case none of the data that makes an action either
'legacy' or 'layered' is there.
The 'animation filtering' code (for showing things in the dope sheet,
graph editor, etc) that I wrote for `Animation` is intentionally kept
around. These types now target 'layered actions' and the
already-existing ones 'legacy actions'. A future PR may merge these two
together, but given how much work it was to add something new there, I'd
rather wait until the dust has settled on this commit.
There are plenty of variables (and some comments) named `anim` or
`animation` that now are of type `animrig::Action`. I haven't renamed
them all, to keep the noise level low in this commit (it's already big
enough). This can be done in a followup, non-functional PR.
Related task: #121355
Pull Request: https://projects.blender.org/blender/blender/pulls/121357
Collections which were pointed by a modifier used to follow visibility of the
current object, and this visibility is static throughout the lifetime of the
dependency graph.
Change the code so that collections pointed by modifiers rely on the visibility
flushing, allowing to be optimized out from evaluation.
Pull Request: https://projects.blender.org/blender/blender/pulls/120516
This is actually a deeper issue, which roots to the fact that updating
relations of the dependency graph does not properly handle cases when an
operation was previously skipped from evaluation (i.e. as a visibility
optimization).
The fix is to preserve needs-update flag throughout relations update of
a dependency graph, similar to the entry tags.
Pull Request: https://projects.blender.org/blender/blender/pulls/120477
Expand the `AnimData` struct with an `Animation *` + an
`binding_stable_index` field, and properly handle those relations.
This also adds functionality for actually pointing animated IDs to
`Animation` data-blocks, and automatically hooking up the relevant
`Binding`.
The Depsgraph code is extended to take these new relations into account,
but doesn't trigger any animation evaluation yet.
For more info, see #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/118677
Regression since 7a2d04a5c4.
Mask evaluation is part of parameters component, and there is no explicit
tags other than copy-on-eval for masks in a lot of cases.
Restore the previous graph topology for the link from copy-on-eval to the
parameters components of mask ID.
Potential candidate for 4.1.1.
Pull Request: https://projects.blender.org/blender/blender/pulls/119956
A regression caused by 7a2d04a5c4.
The offending commit made it so selection tag does not imply parameters
update, which also avoids transitive re-evaluation of the curve geometry.
However, the active curve index is stored on a Curve, and curve modifier
stack creates a copy of the curve to hold the evaluation results, which
makes it so evaluated curve object does not intrinsically share the active
spline index.
This change makes it so changes in selection triggers geometry evaluation
on curves, matching the behavior prior to the offending commit.
AN ideal fix would somehow avoid such geometry re-evaluation, but it would
be a bigger change, not suitable for possible corrective release.
Potential candidate for 4.1.1.
Pull Request: https://projects.blender.org/blender/blender/pulls/119918
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
Introduce new DNA for the `Animation` data-block and its sub-data.
This includes the blenkernel code for reading & writing to blend files,
and for memory management (freeing, duplicating). Minimal C++ wrappers
are included, with just the functionality needed for blenkernel to do
its job.
The Outliner code is extended so that it knows about the new data-type,
nothing more.
For more info, see issue #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/119077
This adds a new `DEG_graph_build_from_collection` function and related
pipeline to more easily build a graph of all relevant IDs from a given
Collection.
It was modeled after the `FromIDsBuilderPipeline` with the difference
being that the list of IDs is gathered from the Collection rather than
passed in. It also slightly differs in that the filtering class shares a
common `Set` rather than building it twice, once for the node builder
and once for the relation builder.
It will eventually be used for the Collection IO project where various
IO exporters will be tied to a Collection and will be limited to just
IDs contained in said Collection.
Pull Request: https://projects.blender.org/blender/blender/pulls/118732
`RootPChanMap` will be nullptr when building DEG object-level
constraints (as as opposed to bone constraints where this map is built
prior), and in that case we don't need to check for the common chains in
`bone_target_opcode`.
Thx @sergey for additional confirmation
Pull Request: https://projects.blender.org/blender/blender/pulls/118745
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 feature is useful for many production scenarios as it allows for the
creation of separate render passes with specific worlds. This would help
workflows that require different skies or other backgrounds for compositing.
Ref #117919
Pull Request: https://projects.blender.org/blender/blender/pulls/117920
This implements layer parenting and layer transforms.
* Adds a new "Transform" panel in the object-data properties with the (local) translation, rotation and scale.
* Adds a new "Relations" panel with the parent property (and also bone name in case the parent is an armature).
* When converting from GPv2 to GPv3, the parent and transforms are converted too.
* Bone names are updated if they are renamed in the armature.
Implementation details:
* The positions in the drawings are always in layer space. During extraction, we transform the positions to object space. Note that this could be optimized further and done in the render engine itself.
* This means that e.g. the selection code (which needs to know where the positions are on screen) now takes this transform into account.
* The layer transform is calculated when accessed (from the location, rotation, scale properties).
* Code that needs to know where the positions are on screen now takes this new transform into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/117247
