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
21 lines
701 B
C++
21 lines
701 B
C++
/* SPDX-FileCopyrightText: 2024 Blender Developers
|
|
*
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
|
|
|
#pragma once
|
|
|
|
namespace blender::animrig::internal {
|
|
|
|
/**
|
|
* Evaluate the animation data on the given layer, for the given slot. This
|
|
* just returns the evaluation result, without taking any other layers,
|
|
* blending, influence, etc. into account.
|
|
*/
|
|
EvaluationResult evaluate_layer(PointerRNA &animated_id_ptr,
|
|
Action &owning_action,
|
|
Layer &layer,
|
|
slot_handle_t slot_handle,
|
|
const AnimationEvalContext &anim_eval_context);
|
|
|
|
} // namespace blender::animrig::internal
|