2023-08-16 00:20:26 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2009 Blender Authors, Joshua Leung. All rights reserved.
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup bke
|
2011-02-27 20:40:57 +00:00
|
|
|
*/
|
|
|
|
|
|
2023-07-22 11:27:25 +10:00
|
|
|
#include <cfloat>
|
|
|
|
|
#include <cmath>
|
|
|
|
|
#include <cstddef>
|
|
|
|
|
#include <cstdio>
|
|
|
|
|
#include <cstring>
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2013-07-28 10:38:25 +00:00
|
|
|
#include "BLI_alloca.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_blenlib.h"
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
#include "BLI_dynstr.h"
|
2013-10-01 16:15:52 +00:00
|
|
|
#include "BLI_listbase.h"
|
2018-12-23 18:43:01 +03:00
|
|
|
#include "BLI_math_rotation.h"
|
|
|
|
|
#include "BLI_math_vector.h"
|
2023-10-18 17:15:30 +02:00
|
|
|
#include "BLI_string_utils.hh"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_utildefines.h"
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
|
2015-08-16 17:32:01 +10:00
|
|
|
#include "BLT_translation.h"
|
2013-03-25 08:29:06 +00:00
|
|
|
|
2009-06-23 13:25:31 +00:00
|
|
|
#include "DNA_anim_types.h"
|
2019-02-27 12:34:56 +11:00
|
|
|
#include "DNA_light_types.h"
|
2010-11-22 23:59:00 +00:00
|
|
|
#include "DNA_material_types.h"
|
2012-03-30 13:04:29 +00:00
|
|
|
#include "DNA_object_types.h"
|
2009-09-19 12:36:22 +00:00
|
|
|
#include "DNA_scene_types.h"
|
2014-10-06 17:03:19 +02:00
|
|
|
#include "DNA_screen_types.h"
|
|
|
|
|
#include "DNA_space_types.h"
|
2010-11-22 23:59:00 +00:00
|
|
|
#include "DNA_texture_types.h"
|
2011-11-02 18:55:32 +00:00
|
|
|
#include "DNA_world_types.h"
|
2009-06-23 13:25:31 +00:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
#include "BKE_action.h"
|
2020-04-03 13:07:36 +02:00
|
|
|
#include "BKE_anim_data.h"
|
2018-11-07 18:00:24 +01:00
|
|
|
#include "BKE_animsys.h"
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BKE_context.hh"
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
#include "BKE_fcurve.h"
|
2009-01-29 23:27:24 +00:00
|
|
|
#include "BKE_global.h"
|
2024-01-15 12:44:04 -05:00
|
|
|
#include "BKE_lib_id.hh"
|
2024-01-18 12:20:42 +01:00
|
|
|
#include "BKE_lib_query.hh"
|
2023-12-01 19:43:16 +01:00
|
|
|
#include "BKE_main.hh"
|
2014-10-06 17:03:19 +02:00
|
|
|
#include "BKE_material.h"
|
2018-11-07 18:00:24 +01:00
|
|
|
#include "BKE_nla.h"
|
2019-05-28 21:02:40 +02:00
|
|
|
#include "BKE_node.h"
|
2011-07-07 03:35:48 +00:00
|
|
|
#include "BKE_report.h"
|
2014-10-06 17:03:19 +02:00
|
|
|
#include "BKE_texture.h"
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
|
2023-09-22 03:18:17 +02:00
|
|
|
#include "DEG_depsgraph.hh"
|
|
|
|
|
#include "DEG_depsgraph_query.hh"
|
2017-04-06 15:37:46 +02:00
|
|
|
|
2023-08-10 22:40:27 +02:00
|
|
|
#include "RNA_access.hh"
|
|
|
|
|
#include "RNA_path.hh"
|
2022-03-14 16:54:46 +01:00
|
|
|
#include "RNA_prototypes.h"
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
|
2023-08-28 15:01:05 +02:00
|
|
|
#include "BLO_read_write.hh"
|
2020-09-10 11:17:35 +02:00
|
|
|
|
2009-06-23 13:25:31 +00:00
|
|
|
#include "nla_private.h"
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
|
2017-12-15 09:43:18 +01:00
|
|
|
#include "atomic_ops.h"
|
|
|
|
|
|
2019-02-01 12:44:19 +11:00
|
|
|
#include "CLG_log.h"
|
|
|
|
|
|
|
|
|
|
static CLG_LogRef LOG = {"bke.anim_sys"};
|
|
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* *********************************** */
|
2009-02-11 12:19:42 +00:00
|
|
|
/* KeyingSet API */
|
|
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* Finding Tools --------------------------- */
|
|
|
|
|
|
2012-05-12 16:11:34 +00:00
|
|
|
KS_Path *BKE_keyingset_find_path(KeyingSet *ks,
|
|
|
|
|
ID *id,
|
|
|
|
|
const char group_name[],
|
|
|
|
|
const char rna_path[],
|
|
|
|
|
int array_index,
|
2023-07-17 10:46:26 +02:00
|
|
|
int /*group_mode*/)
|
2009-02-15 07:00:13 +00:00
|
|
|
{
|
|
|
|
|
/* sanity checks */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, ks, rna_path, id)) {
|
|
|
|
|
return nullptr;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
|
|
|
|
/* loop over paths in the current KeyingSet, finding the first one where all settings match
|
2009-02-15 07:00:13 +00:00
|
|
|
* (i.e. the first one where none of the checks fail and equal 0)
|
|
|
|
|
*/
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (KS_Path *, ksp, &ks->paths) {
|
2012-05-12 16:11:34 +00:00
|
|
|
short eq_id = 1, eq_path = 1, eq_index = 1, eq_group = 1;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* id */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (id != ksp->id) {
|
2012-05-12 16:11:34 +00:00
|
|
|
eq_id = 0;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* path */
|
2023-07-17 10:46:26 +02:00
|
|
|
if ((ksp->rna_path == nullptr) || !STREQ(rna_path, ksp->rna_path)) {
|
2012-05-12 16:11:34 +00:00
|
|
|
eq_path = 0;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-09-04 07:26:32 +00:00
|
|
|
/* index - need to compare whole-array setting too... */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (ksp->array_index != array_index) {
|
2012-05-12 16:11:34 +00:00
|
|
|
eq_index = 0;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* group */
|
|
|
|
|
if (group_name) {
|
2012-07-07 22:51:57 +00:00
|
|
|
/* FIXME: these checks need to be coded... for now, it's not too important though */
|
2009-02-15 07:00:13 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* if all aspects are ok, return */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (eq_id && eq_path && eq_index && eq_group) {
|
2009-02-15 07:00:13 +00:00
|
|
|
return ksp;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2009-02-15 07:00:13 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* none found */
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2009-02-15 07:00:13 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* Defining Tools --------------------------- */
|
|
|
|
|
|
2012-05-12 16:11:34 +00:00
|
|
|
KeyingSet *BKE_keyingset_add(
|
|
|
|
|
ListBase *list, const char idname[], const char name[], short flag, short keyingflag)
|
2009-02-11 12:19:42 +00:00
|
|
|
{
|
|
|
|
|
KeyingSet *ks;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* allocate new KeyingSet */
|
2023-07-17 10:46:26 +02:00
|
|
|
ks = static_cast<KeyingSet *>(MEM_callocN(sizeof(KeyingSet), "KeyingSet"));
|
2010-11-05 07:35:21 +00:00
|
|
|
|
2023-05-13 17:38:48 +10:00
|
|
|
STRNCPY_UTF8(ks->idname, (idname) ? idname : (name) ? name : DATA_("KeyingSet"));
|
|
|
|
|
STRNCPY_UTF8(ks->name, (name) ? name : (idname) ? idname : DATA_("Keying Set"));
|
2010-11-05 07:35:21 +00:00
|
|
|
|
2012-05-12 16:11:34 +00:00
|
|
|
ks->flag = flag;
|
|
|
|
|
ks->keyingflag = keyingflag;
|
2019-04-27 12:07:07 +10:00
|
|
|
/* NOTE: assume that if one is set one way, the other should be too, so that it'll work */
|
|
|
|
|
ks->keyingoverride = keyingflag;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* add KeyingSet to list */
|
|
|
|
|
BLI_addtail(list, ks);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2012-11-06 06:29:40 +00:00
|
|
|
/* Make sure KeyingSet has a unique idname */
|
2013-03-25 08:29:06 +00:00
|
|
|
BLI_uniquename(
|
|
|
|
|
list, ks, DATA_("KeyingSet"), '.', offsetof(KeyingSet, idname), sizeof(ks->idname));
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2012-11-06 06:29:40 +00:00
|
|
|
/* Make sure KeyingSet has a unique label (this helps with identification) */
|
2013-03-25 08:29:06 +00:00
|
|
|
BLI_uniquename(list, ks, DATA_("Keying Set"), '.', offsetof(KeyingSet, name), sizeof(ks->name));
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* return new KeyingSet for further editing */
|
|
|
|
|
return ks;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-12 16:11:34 +00:00
|
|
|
KS_Path *BKE_keyingset_add_path(KeyingSet *ks,
|
|
|
|
|
ID *id,
|
|
|
|
|
const char group_name[],
|
|
|
|
|
const char rna_path[],
|
|
|
|
|
int array_index,
|
|
|
|
|
short flag,
|
|
|
|
|
short groupmode)
|
2009-02-11 12:19:42 +00:00
|
|
|
{
|
|
|
|
|
KS_Path *ksp;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* sanity checks */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, ks, rna_path)) {
|
2019-02-01 12:44:19 +11:00
|
|
|
CLOG_ERROR(&LOG, "no Keying Set and/or RNA Path to add path with");
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2009-08-25 04:05:37 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* ID is required for all types of KeyingSets */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (id == nullptr) {
|
2019-02-01 12:44:19 +11:00
|
|
|
CLOG_ERROR(&LOG, "No ID provided for Keying Set Path");
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2009-02-11 12:19:42 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* don't add if there is already a matching KS_Path in the KeyingSet */
|
2010-02-27 02:03:33 +00:00
|
|
|
if (BKE_keyingset_find_path(ks, id, group_name, rna_path, array_index, groupmode)) {
|
2019-04-22 09:39:35 +10:00
|
|
|
if (G.debug & G_DEBUG) {
|
2019-02-01 12:44:19 +11:00
|
|
|
CLOG_ERROR(&LOG, "destination already exists in Keying Set");
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2009-08-25 04:05:37 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* allocate a new KeyingSet Path */
|
2023-07-17 10:46:26 +02:00
|
|
|
ksp = static_cast<KS_Path *>(MEM_callocN(sizeof(KS_Path), "KeyingSet Path"));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* just store absolute info */
|
2012-05-12 16:11:34 +00:00
|
|
|
ksp->id = id;
|
2019-04-22 09:39:35 +10:00
|
|
|
if (group_name) {
|
2023-05-09 12:50:37 +10:00
|
|
|
STRNCPY(ksp->group, group_name);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
|
|
|
|
else {
|
2012-05-12 16:11:34 +00:00
|
|
|
ksp->group[0] = '\0';
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-04-13 11:15:43 +00:00
|
|
|
/* store additional info for relative paths (just in case user makes the set relative) */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (id) {
|
2012-05-12 16:11:34 +00:00
|
|
|
ksp->idtype = GS(id->name);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* just copy path info */
|
2012-07-06 23:56:59 +00:00
|
|
|
/* TODO: should array index be checked too? */
|
2014-05-29 02:09:45 +10:00
|
|
|
ksp->rna_path = BLI_strdup(rna_path);
|
2012-05-12 16:11:34 +00:00
|
|
|
ksp->array_index = array_index;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* store flags */
|
2012-05-12 16:11:34 +00:00
|
|
|
ksp->flag = flag;
|
|
|
|
|
ksp->groupmode = groupmode;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* add KeyingSet path to KeyingSet */
|
|
|
|
|
BLI_addtail(&ks->paths, ksp);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* return this path */
|
|
|
|
|
return ksp;
|
2018-06-17 17:05:51 +02:00
|
|
|
}
|
2009-02-11 12:19:42 +00:00
|
|
|
|
2012-04-29 17:11:40 +00:00
|
|
|
void BKE_keyingset_free_path(KeyingSet *ks, KS_Path *ksp)
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
{
|
|
|
|
|
/* sanity check */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, ks, ksp)) {
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2011-01-04 08:56:25 +00:00
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* free RNA-path info */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (ksp->rna_path) {
|
2011-01-04 08:56:25 +00:00
|
|
|
MEM_freeN(ksp->rna_path);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2011-01-04 08:56:25 +00:00
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* free path itself */
|
|
|
|
|
BLI_freelinkN(&ks->paths, ksp);
|
|
|
|
|
}
|
|
|
|
|
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
void BKE_keyingsets_copy(ListBase *newlist, const ListBase *list)
|
2009-08-15 16:43:03 +00:00
|
|
|
{
|
|
|
|
|
BLI_duplicatelist(newlist, list);
|
|
|
|
|
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (KeyingSet *, ksn, newlist) {
|
2009-08-15 16:43:03 +00:00
|
|
|
BLI_duplicatelist(&ksn->paths, &ksn->paths);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (KS_Path *, kspn, &ksn->paths) {
|
2023-07-17 10:46:26 +02:00
|
|
|
kspn->rna_path = static_cast<char *>(MEM_dupallocN(kspn->rna_path));
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2009-08-15 16:43:03 +00:00
|
|
|
}
|
|
|
|
|
}
|
2009-02-11 12:19:42 +00:00
|
|
|
|
2022-02-14 12:05:11 +01:00
|
|
|
void BKE_keyingsets_foreach_id(LibraryForeachIDData *data, const ListBase *keyingsets)
|
|
|
|
|
{
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (KeyingSet *, ksn, keyingsets) {
|
|
|
|
|
LISTBASE_FOREACH (KS_Path *, kspn, &ksn->paths) {
|
2022-02-14 12:05:11 +01:00
|
|
|
BKE_LIB_FOREACHID_PROCESS_ID(data, kspn->id, IDWALK_CB_NOP);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* Freeing Tools --------------------------- */
|
|
|
|
|
|
2023-10-13 12:55:54 +02:00
|
|
|
void BKE_keyingset_free_paths(KeyingSet *ks)
|
2009-02-11 12:19:42 +00:00
|
|
|
{
|
|
|
|
|
KS_Path *ksp, *kspn;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* sanity check */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ks == nullptr) {
|
2009-02-11 12:19:42 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* free each path as we go to avoid looping twice */
|
2023-07-17 10:46:26 +02:00
|
|
|
for (ksp = static_cast<KS_Path *>(ks->paths.first); ksp; ksp = kspn) {
|
2012-05-12 16:11:34 +00:00
|
|
|
kspn = ksp->next;
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
BKE_keyingset_free_path(ks, ksp);
|
2009-02-11 12:19:42 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-29 17:11:40 +00:00
|
|
|
void BKE_keyingsets_free(ListBase *list)
|
2009-02-11 12:19:42 +00:00
|
|
|
{
|
|
|
|
|
KeyingSet *ks, *ksn;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* sanity check */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (list == nullptr) {
|
2009-02-11 12:19:42 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
|
|
|
|
/* loop over KeyingSets freeing them
|
2023-10-13 12:55:54 +02:00
|
|
|
* - BKE_keyingset_free_paths() doesn't free the set itself, but it frees its sub-data
|
2009-02-11 12:19:42 +00:00
|
|
|
*/
|
2023-07-17 10:46:26 +02:00
|
|
|
for (ks = static_cast<KeyingSet *>(list->first); ks; ks = ksn) {
|
2012-05-12 16:11:34 +00:00
|
|
|
ksn = ks->next;
|
2023-10-13 12:55:54 +02:00
|
|
|
BKE_keyingset_free_paths(ks);
|
2009-02-11 12:19:42 +00:00
|
|
|
BLI_freelinkN(list, ks);
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-01-18 10:41:45 +00:00
|
|
|
|
2020-09-10 11:17:35 +02:00
|
|
|
void BKE_keyingsets_blend_write(BlendWriter *writer, ListBase *list)
|
|
|
|
|
{
|
|
|
|
|
LISTBASE_FOREACH (KeyingSet *, ks, list) {
|
|
|
|
|
/* KeyingSet */
|
|
|
|
|
BLO_write_struct(writer, KeyingSet, ks);
|
|
|
|
|
|
|
|
|
|
/* Paths */
|
|
|
|
|
LISTBASE_FOREACH (KS_Path *, ksp, &ks->paths) {
|
|
|
|
|
/* Path */
|
|
|
|
|
BLO_write_struct(writer, KS_Path, ksp);
|
|
|
|
|
|
|
|
|
|
if (ksp->rna_path) {
|
|
|
|
|
BLO_write_string(writer, ksp->rna_path);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BKE_keyingsets_blend_read_data(BlendDataReader *reader, ListBase *list)
|
|
|
|
|
{
|
|
|
|
|
LISTBASE_FOREACH (KeyingSet *, ks, list) {
|
|
|
|
|
/* paths */
|
|
|
|
|
BLO_read_list(reader, &ks->paths);
|
|
|
|
|
|
|
|
|
|
LISTBASE_FOREACH (KS_Path *, ksp, &ks->paths) {
|
|
|
|
|
/* rna path */
|
|
|
|
|
BLO_read_data_address(reader, &ksp->rna_path);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* ***************************************** */
|
|
|
|
|
/* Evaluation Data-Setting Backend */
|
|
|
|
|
|
2021-01-14 18:46:28 -05:00
|
|
|
static bool is_fcurve_evaluatable(FCurve *fcu)
|
|
|
|
|
{
|
|
|
|
|
if (fcu->flag & (FCURVE_MUTED | FCURVE_DISABLED)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2023-07-17 10:46:26 +02:00
|
|
|
if (fcu->grp != nullptr && (fcu->grp->flag & AGRP_MUTED)) {
|
2021-01-14 18:46:28 -05:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
if (BKE_fcurve_is_empty(fcu)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
bool BKE_animsys_rna_path_resolve(
|
|
|
|
|
PointerRNA *ptr, /* typically 'fcu->rna_path', 'fcu->array_index' */
|
|
|
|
|
const char *rna_path,
|
|
|
|
|
const int array_index,
|
|
|
|
|
PathResolvedRNA *r_result)
|
2016-07-30 16:34:01 +10:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
if (rna_path == nullptr) {
|
2021-03-01 18:18:20 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-03-01 18:18:20 +01:00
|
|
|
const char *path = rna_path;
|
|
|
|
|
if (!RNA_path_resolve_property(ptr, path, &r_result->ptr, &r_result->prop)) {
|
|
|
|
|
/* failed to get path */
|
|
|
|
|
/* XXX don't tag as failed yet though, as there are some legit situations (Action Constraint)
|
|
|
|
|
* where some channels will not exist, but shouldn't lock up Action */
|
|
|
|
|
if (G.debug & G_DEBUG) {
|
|
|
|
|
CLOG_WARN(&LOG,
|
|
|
|
|
"Animato: Invalid path. ID = '%s', '%s[%d]'",
|
|
|
|
|
(ptr->owner_id) ? (ptr->owner_id->name + 2) : "<No ID>",
|
|
|
|
|
path,
|
|
|
|
|
array_index);
|
2016-07-30 16:34:01 +10:00
|
|
|
}
|
2021-03-01 18:18:20 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ptr->owner_id != nullptr && !RNA_property_animateable(&r_result->ptr, r_result->prop)) {
|
2021-03-01 18:18:20 +01:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int array_len = RNA_property_array_length(&r_result->ptr, r_result->prop);
|
|
|
|
|
if (array_len && array_index >= array_len) {
|
|
|
|
|
if (G.debug & G_DEBUG) {
|
|
|
|
|
CLOG_WARN(&LOG,
|
|
|
|
|
"Animato: Invalid array index. ID = '%s', '%s[%d]', array length is %d",
|
|
|
|
|
(ptr->owner_id) ? (ptr->owner_id->name + 2) : "<No ID>",
|
|
|
|
|
path,
|
|
|
|
|
array_index,
|
|
|
|
|
array_len - 1);
|
2016-07-30 16:34:01 +10:00
|
|
|
}
|
2021-03-01 18:18:20 +01:00
|
|
|
return false;
|
2016-07-30 16:34:01 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-03-01 18:18:20 +01:00
|
|
|
r_result->prop_index = array_len ? array_index : -1;
|
|
|
|
|
return true;
|
2016-07-30 16:34:01 +10:00
|
|
|
}
|
|
|
|
|
|
2014-11-21 14:14:50 +01:00
|
|
|
/* less than 1.0 evaluates to false, use epsilon to avoid float error */
|
2021-08-05 16:48:29 +10:00
|
|
|
#define ANIMSYS_FLOAT_AS_BOOL(value) ((value) > (1.0f - FLT_EPSILON))
|
2011-05-26 05:35:30 +00:00
|
|
|
|
2021-03-01 18:42:48 +01:00
|
|
|
bool BKE_animsys_read_from_rna_path(PathResolvedRNA *anim_rna, float *r_value)
|
2018-04-25 17:46:05 +02:00
|
|
|
{
|
|
|
|
|
PropertyRNA *prop = anim_rna->prop;
|
|
|
|
|
PointerRNA *ptr = &anim_rna->ptr;
|
|
|
|
|
int array_index = anim_rna->prop_index;
|
|
|
|
|
float orig_value;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-25 17:46:05 +02:00
|
|
|
/* caller must ensure this is animatable */
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_assert(RNA_property_animateable(ptr, prop) || ptr->owner_id == nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-25 17:46:05 +02:00
|
|
|
switch (RNA_property_type(prop)) {
|
|
|
|
|
case PROP_BOOLEAN: {
|
|
|
|
|
if (array_index != -1) {
|
|
|
|
|
const int orig_value_coerce = RNA_property_boolean_get_index(ptr, prop, array_index);
|
2023-07-18 14:18:07 +10:00
|
|
|
orig_value = float(orig_value_coerce);
|
2018-04-25 17:46:05 +02:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
const int orig_value_coerce = RNA_property_boolean_get(ptr, prop);
|
2023-07-18 14:18:07 +10:00
|
|
|
orig_value = float(orig_value_coerce);
|
2018-04-25 17:46:05 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case PROP_INT: {
|
|
|
|
|
if (array_index != -1) {
|
|
|
|
|
const int orig_value_coerce = RNA_property_int_get_index(ptr, prop, array_index);
|
2023-07-18 14:18:07 +10:00
|
|
|
orig_value = float(orig_value_coerce);
|
2018-04-25 17:46:05 +02:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
const int orig_value_coerce = RNA_property_int_get(ptr, prop);
|
2023-07-18 14:18:07 +10:00
|
|
|
orig_value = float(orig_value_coerce);
|
2018-04-25 17:46:05 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case PROP_FLOAT: {
|
|
|
|
|
if (array_index != -1) {
|
|
|
|
|
const float orig_value_coerce = RNA_property_float_get_index(ptr, prop, array_index);
|
2023-07-18 14:18:07 +10:00
|
|
|
orig_value = float(orig_value_coerce);
|
2018-04-25 17:46:05 +02:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
const float orig_value_coerce = RNA_property_float_get(ptr, prop);
|
2023-07-18 14:18:07 +10:00
|
|
|
orig_value = float(orig_value_coerce);
|
2018-04-25 17:46:05 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case PROP_ENUM: {
|
|
|
|
|
const int orig_value_coerce = RNA_property_enum_get(ptr, prop);
|
2023-07-18 14:18:07 +10:00
|
|
|
orig_value = float(orig_value_coerce);
|
2018-04-25 17:46:05 +02:00
|
|
|
break;
|
|
|
|
|
}
|
2023-07-17 10:46:26 +02:00
|
|
|
default: /* nothing can be done here... so it is unsuccessful? */
|
2018-04-25 17:46:05 +02:00
|
|
|
return false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (r_value != nullptr) {
|
2018-04-25 17:46:05 +02:00
|
|
|
*r_value = orig_value;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-25 17:46:05 +02:00
|
|
|
/* successful */
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-01 18:42:48 +01:00
|
|
|
bool BKE_animsys_write_to_rna_path(PathResolvedRNA *anim_rna, const float value)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
2016-07-30 16:34:01 +10:00
|
|
|
PropertyRNA *prop = anim_rna->prop;
|
2016-07-30 16:47:18 +10:00
|
|
|
PointerRNA *ptr = &anim_rna->ptr;
|
2016-07-30 16:34:01 +10:00
|
|
|
int array_index = anim_rna->prop_index;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-07-30 16:47:18 +10:00
|
|
|
/* caller must ensure this is animatable */
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_assert(RNA_property_animateable(ptr, prop) || ptr->owner_id == nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-25 17:46:05 +02:00
|
|
|
/* Check whether value is new. Otherwise we skip all the updates. */
|
|
|
|
|
float old_value;
|
2021-03-01 18:42:48 +01:00
|
|
|
if (!BKE_animsys_read_from_rna_path(anim_rna, &old_value)) {
|
2018-04-25 17:46:05 +02:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
if (old_value == value) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-07-30 16:47:18 +10:00
|
|
|
switch (RNA_property_type(prop)) {
|
|
|
|
|
case PROP_BOOLEAN: {
|
|
|
|
|
const int value_coerce = ANIMSYS_FLOAT_AS_BOOL(value);
|
|
|
|
|
if (array_index != -1) {
|
2018-04-25 17:46:05 +02:00
|
|
|
RNA_property_boolean_set_index(ptr, prop, array_index, value_coerce);
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
2016-07-30 16:47:18 +10:00
|
|
|
else {
|
2018-04-25 17:46:05 +02:00
|
|
|
RNA_property_boolean_set(ptr, prop, value_coerce);
|
== RNA Property Updates get called by Animation System now ==
This fixes bug #26764 and several others like it, where modifier
properties (and others, but most visibly modifiers) would not do
anything when animated or driven, as modifier properties require the
RNA update calls to tag the modifiers to get recalculated.
While just adding a call to RNA_property_update() could have gotten
this working (as per the Campbell's patch attached in the report, and
also my own attempt #25881). However, on production rigs, the
performance cost of this is untenatable (on my own tests, without
these updates, I was getting ~5fps on such a rig, but only 0.9fps or
possibly even worse with the updates added).
Hence, this commit adds a property-update caching system to the RNA
level, which aims to reduce to the number of times that the update
functions end up needing to get called.
While this is much faster than without the caching, I also added an
optimisation for pose bones (which are numerous in production rigs) so
that their property updates are skipped, since they are useless to the
animsys (they only tag the depsgraph for updating). This gets things
moving at a more acceptable framerate.
2011-07-24 04:34:46 +00:00
|
|
|
}
|
2016-07-30 16:47:18 +10:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case PROP_INT: {
|
2023-07-18 14:18:07 +10:00
|
|
|
int value_coerce = int(value);
|
2017-07-07 12:08:14 +02:00
|
|
|
RNA_property_int_clamp(ptr, prop, &value_coerce);
|
2016-07-30 16:47:18 +10:00
|
|
|
if (array_index != -1) {
|
2018-04-25 17:46:05 +02:00
|
|
|
RNA_property_int_set_index(ptr, prop, array_index, value_coerce);
|
2016-07-30 16:47:18 +10:00
|
|
|
}
|
|
|
|
|
else {
|
2018-04-25 17:46:05 +02:00
|
|
|
RNA_property_int_set(ptr, prop, value_coerce);
|
2011-11-03 10:03:08 +00:00
|
|
|
}
|
2016-07-30 16:47:18 +10:00
|
|
|
break;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
2016-07-30 16:47:18 +10:00
|
|
|
case PROP_FLOAT: {
|
2017-07-07 12:08:14 +02:00
|
|
|
float value_coerce = value;
|
|
|
|
|
RNA_property_float_clamp(ptr, prop, &value_coerce);
|
2016-07-30 16:47:18 +10:00
|
|
|
if (array_index != -1) {
|
2018-04-25 17:46:05 +02:00
|
|
|
RNA_property_float_set_index(ptr, prop, array_index, value_coerce);
|
2016-07-30 16:47:18 +10:00
|
|
|
}
|
|
|
|
|
else {
|
2018-04-25 17:46:05 +02:00
|
|
|
RNA_property_float_set(ptr, prop, value_coerce);
|
2016-07-30 16:47:18 +10:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case PROP_ENUM: {
|
2023-07-18 14:18:07 +10:00
|
|
|
const int value_coerce = int(value);
|
2018-04-25 17:46:05 +02:00
|
|
|
RNA_property_enum_set(ptr, prop, value_coerce);
|
2016-07-30 16:47:18 +10:00
|
|
|
break;
|
|
|
|
|
}
|
2023-07-17 10:46:26 +02:00
|
|
|
default: /* nothing can be done here... so it is unsuccessful? */
|
2016-07-30 16:47:18 +10:00
|
|
|
return false;
|
2009-01-27 05:04:23 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-07-30 16:47:18 +10:00
|
|
|
/* successful */
|
|
|
|
|
return true;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
2019-04-30 10:45:11 +02:00
|
|
|
static bool animsys_construct_orig_pointer_rna(const PointerRNA *ptr, PointerRNA *ptr_orig)
|
|
|
|
|
{
|
|
|
|
|
*ptr_orig = *ptr;
|
2023-07-17 10:46:26 +02:00
|
|
|
/* NOTE: nlastrip_evaluate_controls() creates PointerRNA with ID of nullptr. Technically, this is
|
2019-04-30 10:45:11 +02:00
|
|
|
* not a valid pointer, but there are exceptions in various places of this file which handles
|
|
|
|
|
* such pointers.
|
|
|
|
|
* We do special trickery here as well, to quickly go from evaluated to original NlaStrip. */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ptr->owner_id == nullptr) {
|
2019-04-30 10:45:11 +02:00
|
|
|
if (ptr->type != &RNA_NlaStrip) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
NlaStrip *strip = ((NlaStrip *)ptr_orig->data);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (strip->orig_strip == nullptr) {
|
2019-04-30 10:45:11 +02:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
ptr_orig->data = strip->orig_strip;
|
|
|
|
|
}
|
|
|
|
|
else {
|
2019-08-23 09:52:12 +02:00
|
|
|
ptr_orig->owner_id = ptr_orig->owner_id->orig_id;
|
|
|
|
|
ptr_orig->data = ptr_orig->owner_id;
|
2019-04-30 10:45:11 +02:00
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-31 14:27:37 +02:00
|
|
|
static void animsys_write_orig_anim_rna(PointerRNA *ptr,
|
2018-11-07 19:47:22 +03:00
|
|
|
const char *rna_path,
|
|
|
|
|
int array_index,
|
2018-05-31 14:27:37 +02:00
|
|
|
float value)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
2019-04-30 10:45:11 +02:00
|
|
|
PointerRNA ptr_orig;
|
|
|
|
|
if (!animsys_construct_orig_pointer_rna(ptr, &ptr_orig)) {
|
2018-10-29 11:06:53 +01:00
|
|
|
return;
|
|
|
|
|
}
|
2018-05-31 14:27:37 +02:00
|
|
|
PathResolvedRNA orig_anim_rna;
|
2019-04-30 10:45:11 +02:00
|
|
|
/* TODO(sergey): Should be possible to cache resolved path in dependency graph somehow. */
|
2021-03-01 18:42:48 +01:00
|
|
|
if (BKE_animsys_rna_path_resolve(&ptr_orig, rna_path, array_index, &orig_anim_rna)) {
|
|
|
|
|
BKE_animsys_write_to_rna_path(&orig_anim_rna, value);
|
2018-05-31 14:27:37 +02:00
|
|
|
}
|
|
|
|
|
}
|
2018-04-25 17:59:08 +02:00
|
|
|
|
2019-04-27 12:07:07 +10:00
|
|
|
/**
|
|
|
|
|
* Evaluate all the F-Curves in the given list
|
|
|
|
|
* This performs a set of standard checks. If extra checks are required,
|
|
|
|
|
* separate code should be used.
|
2018-05-31 14:27:37 +02:00
|
|
|
*/
|
2019-07-31 14:56:17 +02:00
|
|
|
static void animsys_evaluate_fcurves(PointerRNA *ptr,
|
2018-11-12 19:30:25 +03:00
|
|
|
ListBase *list,
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const AnimationEvalContext *anim_eval_context,
|
2019-07-31 14:56:17 +02:00
|
|
|
bool flush_to_original)
|
2018-05-31 14:27:37 +02:00
|
|
|
{
|
2018-05-31 11:09:48 +02:00
|
|
|
/* Calculate then execute each curve. */
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (FCurve *, fcu, list) {
|
2021-01-14 18:46:28 -05:00
|
|
|
|
|
|
|
|
if (!is_fcurve_evaluatable(fcu)) {
|
2019-05-15 22:26:58 +03:00
|
|
|
continue;
|
|
|
|
|
}
|
2021-01-14 18:46:28 -05:00
|
|
|
|
2018-05-31 11:09:48 +02:00
|
|
|
PathResolvedRNA anim_rna;
|
2021-03-01 18:42:48 +01:00
|
|
|
if (BKE_animsys_rna_path_resolve(ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const float curval = calculate_fcurve(&anim_rna, fcu, anim_eval_context);
|
2021-03-01 18:42:48 +01:00
|
|
|
BKE_animsys_write_to_rna_path(&anim_rna, curval);
|
2019-07-31 14:56:17 +02:00
|
|
|
if (flush_to_original) {
|
2018-11-12 19:30:25 +03:00
|
|
|
animsys_write_orig_anim_rna(ptr, fcu->rna_path, fcu->array_index, curval);
|
2009-07-03 10:28:10 +00:00
|
|
|
}
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-09 11:25:48 +02:00
|
|
|
/**
|
|
|
|
|
* This function assumes that the quaternion keys are sequential. They do not
|
|
|
|
|
* have to be in array_index order. If the quaternion is only partially keyed,
|
|
|
|
|
* the result is normalized. If it is fully keyed, the result is returned as-is.
|
|
|
|
|
*
|
|
|
|
|
* \return the number of FCurves used to construct this quaternion. This is so
|
|
|
|
|
* that the caller knows how many FCurves can be skipped while iterating over
|
|
|
|
|
* them. */
|
|
|
|
|
static int animsys_quaternion_evaluate_fcurves(PathResolvedRNA quat_rna,
|
|
|
|
|
FCurve *first_fcurve,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
float r_quaternion[4])
|
2021-07-02 13:47:53 +02:00
|
|
|
{
|
|
|
|
|
FCurve *quat_curve_fcu = first_fcurve;
|
2023-05-08 13:53:58 +02:00
|
|
|
|
|
|
|
|
/* Initialize r_quaternion to the unit quaternion so that half-keyed quaternions at least have
|
|
|
|
|
* *some* value in there. */
|
|
|
|
|
r_quaternion[0] = 1.0f;
|
|
|
|
|
r_quaternion[1] = 0.0f;
|
|
|
|
|
r_quaternion[2] = 0.0f;
|
|
|
|
|
r_quaternion[3] = 0.0f;
|
|
|
|
|
|
2023-05-09 11:25:48 +02:00
|
|
|
int fcurve_offset = 0;
|
|
|
|
|
for (; fcurve_offset < 4 && quat_curve_fcu;
|
2024-01-02 18:12:54 +01:00
|
|
|
++fcurve_offset, quat_curve_fcu = quat_curve_fcu->next)
|
|
|
|
|
{
|
2023-05-09 11:25:48 +02:00
|
|
|
if (!STREQ(quat_curve_fcu->rna_path, first_fcurve->rna_path)) {
|
|
|
|
|
/* This should never happen when the quaternion is fully keyed. Some
|
|
|
|
|
* people do use half-keyed quaternions, though, so better to check. */
|
2023-05-08 13:53:58 +02:00
|
|
|
break;
|
|
|
|
|
}
|
2021-07-02 13:47:53 +02:00
|
|
|
|
2023-05-09 11:25:48 +02:00
|
|
|
const int array_index = quat_curve_fcu->array_index;
|
|
|
|
|
quat_rna.prop_index = array_index;
|
|
|
|
|
r_quaternion[array_index] = calculate_fcurve(&quat_rna, quat_curve_fcu, anim_eval_context);
|
2021-07-02 13:47:53 +02:00
|
|
|
}
|
2023-05-08 13:53:58 +02:00
|
|
|
|
2023-05-09 11:25:48 +02:00
|
|
|
if (fcurve_offset < 4) {
|
2023-05-20 21:17:09 +10:00
|
|
|
/* This quaternion was incompletely keyed, so the result is a mixture of the unit quaternion
|
|
|
|
|
* and values from FCurves. This means that it's almost certainly no longer of unit length. */
|
2023-05-08 13:53:58 +02:00
|
|
|
normalize_qt(r_quaternion);
|
|
|
|
|
}
|
2023-05-09 11:25:48 +02:00
|
|
|
|
|
|
|
|
return fcurve_offset;
|
2021-07-02 13:47:53 +02:00
|
|
|
}
|
|
|
|
|
|
2023-05-09 11:25:48 +02:00
|
|
|
/**
|
|
|
|
|
* This function assumes that the quaternion keys are sequential. They do not
|
|
|
|
|
* have to be in array_index order.
|
|
|
|
|
*
|
|
|
|
|
* \return the number of FCurves used to construct the quaternion, counting from
|
|
|
|
|
* `first_fcurve`. This is so that the caller knows how many FCurves can be
|
|
|
|
|
* skipped while iterating over them. */
|
|
|
|
|
static int animsys_blend_fcurves_quaternion(PathResolvedRNA *anim_rna,
|
|
|
|
|
FCurve *first_fcurve,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
const float blend_factor)
|
2021-07-02 13:47:53 +02:00
|
|
|
{
|
|
|
|
|
float current_quat[4];
|
|
|
|
|
RNA_property_float_get_array(&anim_rna->ptr, anim_rna->prop, current_quat);
|
|
|
|
|
|
|
|
|
|
float target_quat[4];
|
2023-05-09 11:25:48 +02:00
|
|
|
const int num_fcurves_read = animsys_quaternion_evaluate_fcurves(
|
|
|
|
|
*anim_rna, first_fcurve, anim_eval_context, target_quat);
|
2021-07-02 13:47:53 +02:00
|
|
|
|
|
|
|
|
float blended_quat[4];
|
|
|
|
|
interp_qt_qtqt(blended_quat, current_quat, target_quat, blend_factor);
|
|
|
|
|
|
|
|
|
|
RNA_property_float_set_array(&anim_rna->ptr, anim_rna->prop, blended_quat);
|
2023-05-09 11:25:48 +02:00
|
|
|
|
|
|
|
|
return num_fcurves_read;
|
2021-07-02 13:47:53 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* LERP between current value (blend_factor=0.0) and the value from the FCurve (blend_factor=1.0)
|
|
|
|
|
*/
|
|
|
|
|
static void animsys_blend_in_fcurves(PointerRNA *ptr,
|
|
|
|
|
ListBase *fcurves,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
const float blend_factor)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
char *channel_to_skip = nullptr;
|
2021-07-02 13:47:53 +02:00
|
|
|
int num_channels_to_skip = 0;
|
|
|
|
|
LISTBASE_FOREACH (FCurve *, fcu, fcurves) {
|
|
|
|
|
|
|
|
|
|
if (num_channels_to_skip) {
|
|
|
|
|
/* For skipping already-handled rotation channels. Rotation channels are handled per group,
|
|
|
|
|
* and not per individual channel. */
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_assert(channel_to_skip != nullptr);
|
2021-07-02 13:47:53 +02:00
|
|
|
if (STREQ(channel_to_skip, fcu->rna_path)) {
|
|
|
|
|
/* This is indeed the channel we want to skip. */
|
|
|
|
|
num_channels_to_skip--;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!is_fcurve_evaluatable(fcu)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PathResolvedRNA anim_rna;
|
|
|
|
|
if (!BKE_animsys_rna_path_resolve(ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (STREQ(RNA_property_identifier(anim_rna.prop), "rotation_quaternion")) {
|
2023-05-09 11:25:48 +02:00
|
|
|
const int num_fcurves_read = animsys_blend_fcurves_quaternion(
|
|
|
|
|
&anim_rna, fcu, anim_eval_context, blend_factor);
|
2021-07-02 13:47:53 +02:00
|
|
|
|
|
|
|
|
/* Skip the next three channels, because those have already been handled here. */
|
|
|
|
|
MEM_SAFE_FREE(channel_to_skip);
|
|
|
|
|
channel_to_skip = BLI_strdup(fcu->rna_path);
|
2023-05-09 11:25:48 +02:00
|
|
|
num_channels_to_skip = num_fcurves_read - 1;
|
2021-07-02 13:47:53 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
/* TODO(Sybren): do something similar as above for Euler and Axis/Angle representations. */
|
|
|
|
|
|
|
|
|
|
const float fcurve_value = calculate_fcurve(&anim_rna, fcu, anim_eval_context);
|
|
|
|
|
|
|
|
|
|
float current_value;
|
|
|
|
|
float value_to_write;
|
|
|
|
|
if (BKE_animsys_read_from_rna_path(&anim_rna, ¤t_value)) {
|
|
|
|
|
value_to_write = (1 - blend_factor) * current_value + blend_factor * fcurve_value;
|
|
|
|
|
|
|
|
|
|
switch (RNA_property_type(anim_rna.prop)) {
|
2023-07-17 10:46:26 +02:00
|
|
|
case PROP_BOOLEAN: /* Without this, anything less than 1.0 is converted to 'False' by
|
|
|
|
|
* ANIMSYS_FLOAT_AS_BOOL(). This is probably not desirable for blends,
|
|
|
|
|
* where anything
|
|
|
|
|
* above a 50% blend should act more like the FCurve than like the
|
|
|
|
|
* current value. */
|
2021-07-02 13:47:53 +02:00
|
|
|
case PROP_INT:
|
|
|
|
|
case PROP_ENUM:
|
|
|
|
|
value_to_write = roundf(value_to_write);
|
|
|
|
|
break;
|
2023-08-09 11:17:04 +10:00
|
|
|
/* All other types are just handled as float, and value_to_write is already correct. */
|
|
|
|
|
default:
|
2021-07-02 13:47:53 +02:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* Unable to read the current value for blending, so just apply the FCurve value instead. */
|
|
|
|
|
value_to_write = fcurve_value;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BKE_animsys_write_to_rna_path(&anim_rna, value_to_write);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MEM_SAFE_FREE(channel_to_skip);
|
|
|
|
|
}
|
|
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* ***************************************** */
|
|
|
|
|
/* Driver Evaluation */
|
|
|
|
|
|
2023-06-03 08:36:28 +10:00
|
|
|
AnimationEvalContext BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float eval_time)
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
AnimationEvalContext ctx{};
|
|
|
|
|
ctx.depsgraph = depsgraph;
|
|
|
|
|
ctx.eval_time = eval_time;
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
return ctx;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
AnimationEvalContext BKE_animsys_eval_context_construct_at(
|
|
|
|
|
const AnimationEvalContext *anim_eval_context, float eval_time)
|
|
|
|
|
{
|
|
|
|
|
return BKE_animsys_eval_context_construct(anim_eval_context->depsgraph, eval_time);
|
|
|
|
|
}
|
|
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* Evaluate Drivers */
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
static void animsys_evaluate_drivers(PointerRNA *ptr,
|
|
|
|
|
AnimData *adt,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
|
|
|
|
/* drivers are stored as F-Curves, but we cannot use the standard code, as we need to check if
|
|
|
|
|
* the depsgraph requested that this driver be evaluated...
|
|
|
|
|
*/
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (FCurve *, fcu, &adt->drivers) {
|
2012-05-12 16:11:34 +00:00
|
|
|
ChannelDriver *driver = fcu->driver;
|
2014-04-11 11:25:41 +10:00
|
|
|
bool ok = false;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* check if this driver's curve should be skipped */
|
2012-05-12 16:11:34 +00:00
|
|
|
if ((fcu->flag & (FCURVE_MUTED | FCURVE_DISABLED)) == 0) {
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* check if driver itself is tagged for recalculation */
|
2012-06-12 08:32:06 +00:00
|
|
|
/* XXX driver recalc flag is not set yet by depsgraph! */
|
2019-01-29 11:59:17 +01:00
|
|
|
if ((driver) && !(driver->flag & DRIVER_FLAG_INVALID)) {
|
2012-06-12 08:32:06 +00:00
|
|
|
/* evaluate this using values set already in other places
|
2019-04-27 12:07:07 +10:00
|
|
|
* NOTE: for 'layering' option later on, we should check if we should remove old value
|
|
|
|
|
* before adding new to only be done when drivers only changed. */
|
2016-07-30 16:34:01 +10:00
|
|
|
PathResolvedRNA anim_rna;
|
2021-03-01 18:42:48 +01:00
|
|
|
if (BKE_animsys_rna_path_resolve(ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const float curval = calculate_fcurve(&anim_rna, fcu, anim_eval_context);
|
2021-03-01 18:42:48 +01:00
|
|
|
ok = BKE_animsys_write_to_rna_path(&anim_rna, curval);
|
2016-07-30 16:34:01 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-04-11 06:48:39 +00:00
|
|
|
/* set error-flag if evaluation failed */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (ok == 0) {
|
2018-06-17 17:05:51 +02:00
|
|
|
driver->flag |= DRIVER_FLAG_INVALID;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ***************************************** */
|
|
|
|
|
/* Actions Evaluation */
|
|
|
|
|
|
2011-04-19 13:01:50 +00:00
|
|
|
/* strictly not necessary for actual "evaluation", but it is a useful safety check
|
|
|
|
|
* to reduce the amount of times that users end up having to "revive" wrongly-assigned
|
|
|
|
|
* actions
|
|
|
|
|
*/
|
2012-05-12 16:11:34 +00:00
|
|
|
static void action_idcode_patch_check(ID *id, bAction *act)
|
2011-04-19 13:01:50 +00:00
|
|
|
{
|
|
|
|
|
int idcode = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-19 13:01:50 +00:00
|
|
|
/* just in case */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, id, act)) {
|
2011-04-19 13:01:50 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
|
|
|
|
|
idcode = GS(id->name);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-04-19 13:01:50 +00:00
|
|
|
/* the actual checks... hopefully not too much of a performance hit in the long run... */
|
|
|
|
|
if (act->idroot == 0) {
|
2019-04-27 12:07:07 +10:00
|
|
|
/* use the current root if not set already
|
|
|
|
|
* (i.e. newly created actions and actions from 2.50-2.57 builds).
|
2018-11-14 12:53:15 +11:00
|
|
|
* - this has problems if there are 2 users, and the first one encountered is the invalid one
|
|
|
|
|
* in which case, the user will need to manually fix this (?)
|
2011-04-19 13:01:50 +00:00
|
|
|
*/
|
|
|
|
|
act->idroot = idcode;
|
|
|
|
|
}
|
|
|
|
|
else if (act->idroot != idcode) {
|
|
|
|
|
/* only report this error if debug mode is enabled (to save performance everywhere else) */
|
2012-03-31 00:59:17 +00:00
|
|
|
if (G.debug & G_DEBUG) {
|
2011-04-19 13:01:50 +00:00
|
|
|
printf(
|
|
|
|
|
"AnimSys Safety Check Failed: Action '%s' is not meant to be used from ID-Blocks of "
|
|
|
|
|
"type %d such as '%s'\n",
|
2012-05-12 16:11:34 +00:00
|
|
|
act->id.name + 2,
|
|
|
|
|
idcode,
|
|
|
|
|
id->name);
|
2011-04-19 13:01:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ----------------------------------------- */
|
|
|
|
|
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
void animsys_evaluate_action_group(PointerRNA *ptr,
|
|
|
|
|
bAction *act,
|
|
|
|
|
bActionGroup *agrp,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context)
|
2009-04-15 01:10:36 +00:00
|
|
|
{
|
|
|
|
|
FCurve *fcu;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
/* check if mapper is appropriate for use here (we set to nullptr if it's inappropriate) */
|
|
|
|
|
if (ELEM(nullptr, act, agrp)) {
|
2012-03-25 22:35:18 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2019-08-23 09:52:12 +02:00
|
|
|
action_idcode_patch_check(ptr->owner_id, act);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-07-03 10:28:10 +00:00
|
|
|
/* if group is muted, don't evaluated any of the F-Curve */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (agrp->flag & AGRP_MUTED) {
|
2009-07-03 10:28:10 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-04-15 01:10:36 +00:00
|
|
|
/* calculate then execute each curve */
|
2023-07-17 10:46:26 +02:00
|
|
|
for (fcu = static_cast<FCurve *>(agrp->channels.first); (fcu) && (fcu->grp == agrp);
|
|
|
|
|
fcu = fcu->next)
|
|
|
|
|
{
|
2009-04-15 01:10:36 +00:00
|
|
|
/* check if this curve should be skipped */
|
2019-05-16 09:47:57 +03:00
|
|
|
if ((fcu->flag & (FCURVE_MUTED | FCURVE_DISABLED)) == 0 && !BKE_fcurve_is_empty(fcu)) {
|
2016-07-30 16:34:01 +10:00
|
|
|
PathResolvedRNA anim_rna;
|
2021-03-01 18:42:48 +01:00
|
|
|
if (BKE_animsys_rna_path_resolve(ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const float curval = calculate_fcurve(&anim_rna, fcu, anim_eval_context);
|
2021-03-01 18:42:48 +01:00
|
|
|
BKE_animsys_write_to_rna_path(&anim_rna, curval);
|
2016-07-30 16:34:01 +10:00
|
|
|
}
|
2009-04-15 01:10:36 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-01 17:37:26 +01:00
|
|
|
void animsys_evaluate_action(PointerRNA *ptr,
|
|
|
|
|
bAction *act,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
const bool flush_to_original)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
/* check if mapper is appropriate for use here (we set to nullptr if it's inappropriate) */
|
|
|
|
|
if (act == nullptr) {
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2019-08-23 09:52:12 +02:00
|
|
|
action_idcode_patch_check(ptr->owner_id, act);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* calculate then execute each curve */
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
animsys_evaluate_fcurves(ptr, &act->curves, anim_eval_context, flush_to_original);
|
2018-04-25 17:59:08 +02:00
|
|
|
}
|
|
|
|
|
|
2021-07-02 13:47:53 +02:00
|
|
|
void animsys_blend_in_action(PointerRNA *ptr,
|
|
|
|
|
bAction *act,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
const float blend_factor)
|
|
|
|
|
{
|
|
|
|
|
action_idcode_patch_check(ptr->owner_id, act);
|
|
|
|
|
animsys_blend_in_fcurves(ptr, &act->curves, anim_eval_context, blend_factor);
|
|
|
|
|
}
|
|
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* ***************************************** */
|
|
|
|
|
/* NLA System - Evaluation */
|
|
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* calculate influence of strip based for given frame based on blendin/out values */
|
2012-05-12 16:11:34 +00:00
|
|
|
static float nlastrip_get_influence(NlaStrip *strip, float cframe)
|
2009-05-03 11:46:57 +00:00
|
|
|
{
|
2012-03-04 04:35:12 +00:00
|
|
|
/* sanity checks - normalize the blendin/out values? */
|
2012-05-12 16:11:34 +00:00
|
|
|
strip->blendin = fabsf(strip->blendin);
|
|
|
|
|
strip->blendout = fabsf(strip->blendout);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* result depends on where frame is in respect to blendin/out values */
|
2013-11-10 12:56:50 +00:00
|
|
|
if (IS_EQF(strip->blendin, 0.0f) == false && (cframe <= (strip->start + strip->blendin))) {
|
2009-05-03 11:46:57 +00:00
|
|
|
/* there is some blend-in */
|
2011-11-19 01:10:05 +00:00
|
|
|
return fabsf(cframe - strip->start) / (strip->blendin);
|
2009-05-03 11:46:57 +00:00
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
if (IS_EQF(strip->blendout, 0.0f) == false && (cframe >= (strip->end - strip->blendout))) {
|
2009-05-03 11:46:57 +00:00
|
|
|
/* there is some blend-out */
|
2011-11-19 01:10:05 +00:00
|
|
|
return fabsf(strip->end - cframe) / (strip->blendout);
|
2009-05-03 11:46:57 +00:00
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
|
|
|
|
|
/* in the middle of the strip, we should be full strength */
|
|
|
|
|
return 1.0f;
|
2009-05-03 11:46:57 +00:00
|
|
|
}
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* evaluate the evaluation time and influence for the strip, storing the results in the strip */
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
static void nlastrip_evaluate_controls(NlaStrip *strip,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
const bool flush_to_original)
|
2009-05-03 11:46:57 +00:00
|
|
|
{
|
|
|
|
|
/* now strip's evaluate F-Curves for these settings (if applicable) */
|
|
|
|
|
if (strip->fcurves.first) {
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* create RNA-pointer needed to set values */
|
2023-09-06 00:48:50 +02:00
|
|
|
PointerRNA strip_ptr = RNA_pointer_create(nullptr, &RNA_NlaStrip, strip);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* execute these settings as per normal */
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
animsys_evaluate_fcurves(&strip_ptr, &strip->fcurves, anim_eval_context, flush_to_original);
|
2009-05-03 11:46:57 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2015-03-13 19:05:27 +13:00
|
|
|
/* analytically generate values for influence and time (if applicable)
|
2018-11-14 12:53:15 +11:00
|
|
|
* - we do this after the F-Curves have been evaluated to override the effects of those
|
|
|
|
|
* in case the override has been turned off.
|
2015-03-13 19:05:27 +13:00
|
|
|
*/
|
2019-04-22 09:39:35 +10:00
|
|
|
if ((strip->flag & NLASTRIP_FLAG_USR_INFLUENCE) == 0) {
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
strip->influence = nlastrip_get_influence(strip, anim_eval_context->eval_time);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
merge own commits into render branch into trunk since 27560
27562, 27570, 27571, 27574, 27576, 27577, 27579, 27590, 27591, 27594, 27595, 27596, 27599, 27605, 27611, 27612, 27613, 27614, 27623
2010-03-20 16:41:01 +00:00
|
|
|
|
2019-01-12 14:10:09 +03:00
|
|
|
/* Bypass evaluation time computation if time mapping is disabled. */
|
|
|
|
|
if ((strip->flag & NLASTRIP_FLAG_NO_TIME_MAP) != 0) {
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
strip->strip_time = anim_eval_context->eval_time;
|
2019-01-12 14:10:09 +03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if ((strip->flag & NLASTRIP_FLAG_USR_TIME) == 0) {
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
strip->strip_time = nlastrip_get_frame(
|
|
|
|
|
strip, anim_eval_context->eval_time, NLATIME_CONVERT_EVAL);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-01-12 14:10:09 +03:00
|
|
|
|
2019-04-27 12:07:07 +10:00
|
|
|
/* if user can control the evaluation time (using F-Curves), consider the option which allows
|
|
|
|
|
* this time to be clamped to lie within extents of the action-clip, so that a steady changing
|
|
|
|
|
* rate of progress through several cycles of the clip can be achieved easily.
|
Keying Sets: BuiltIn vs Absolute Tweaks
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
2010-03-23 11:59:34 +00:00
|
|
|
*/
|
2012-07-06 23:56:59 +00:00
|
|
|
/* NOTE: if we add any more of these special cases, we better group them up nicely... */
|
2019-04-22 09:39:35 +10:00
|
|
|
if ((strip->flag & NLASTRIP_FLAG_USR_TIME) && (strip->flag & NLASTRIP_FLAG_USR_TIME_CYCLIC)) {
|
2012-05-12 16:11:34 +00:00
|
|
|
strip->strip_time = fmod(strip->strip_time - strip->actstart, strip->actend - strip->actstart);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2009-05-03 11:46:57 +00:00
|
|
|
}
|
|
|
|
|
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
NlaEvalStrip *nlastrips_ctime_get_strip(ListBase *list,
|
|
|
|
|
ListBase *strips,
|
|
|
|
|
short index,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
const bool flush_to_original)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
2023-08-04 08:51:13 +10:00
|
|
|
NlaStrip *estrip = nullptr;
|
2009-07-07 11:37:33 +00:00
|
|
|
NlaEvalStrip *nes;
|
2012-05-12 16:11:34 +00:00
|
|
|
short side = 0;
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
float ctime = anim_eval_context->eval_time;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* loop over strips, checking if they fall within the range */
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (NlaStrip *, strip, strips) {
|
2021-06-24 15:56:58 +10:00
|
|
|
/* Check if current time occurs within this strip. */
|
2023-09-11 18:40:31 +02:00
|
|
|
|
|
|
|
|
/* This block leads to the Action Track and non-time-remapped tweak strip evaluation to respect
|
|
|
|
|
* the extrapolation modes. If in_range, these two tracks will always output NES_TIME_WITHIN so
|
|
|
|
|
* fcurve extrapolation isn't clamped to the keyframe bounds. */
|
|
|
|
|
bool in_range = IN_RANGE_INCL(ctime, strip->start, strip->end);
|
|
|
|
|
if (strip->flag & NLASTRIP_FLAG_NO_TIME_MAP) {
|
|
|
|
|
switch (strip->extendmode) {
|
|
|
|
|
case NLASTRIP_EXTEND_HOLD:
|
|
|
|
|
in_range = true;
|
|
|
|
|
break;
|
|
|
|
|
case NLASTRIP_EXTEND_HOLD_FORWARD:
|
|
|
|
|
in_range = ctime >= strip->start;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (in_range) {
|
2009-05-03 11:46:57 +00:00
|
|
|
/* this strip is active, so try to use it */
|
2012-05-12 16:11:34 +00:00
|
|
|
estrip = strip;
|
|
|
|
|
side = NES_TIME_WITHIN;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
break;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* if time occurred before current strip... */
|
|
|
|
|
if (ctime < strip->start) {
|
2009-07-06 03:44:44 +00:00
|
|
|
if (strip == strips->first) {
|
2009-05-03 11:46:57 +00:00
|
|
|
/* before first strip - only try to use it if it extends backwards in time too */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (strip->extendmode == NLASTRIP_EXTEND_HOLD) {
|
2012-05-12 16:11:34 +00:00
|
|
|
estrip = strip;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* side is 'before' regardless of whether there's a useful strip */
|
2012-05-12 16:11:34 +00:00
|
|
|
side = NES_TIME_BEFORE;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2018-06-17 17:05:51 +02:00
|
|
|
/* before next strip - previous strip has ended, but next hasn't begun,
|
2009-05-03 11:46:57 +00:00
|
|
|
* so blending mode depends on whether strip is being held or not...
|
2018-11-14 12:53:15 +11:00
|
|
|
* - only occurs when no transition strip added, otherwise the transition would have
|
|
|
|
|
* been picked up above...
|
2009-05-03 11:46:57 +00:00
|
|
|
*/
|
2012-05-12 16:11:34 +00:00
|
|
|
strip = strip->prev;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (strip->extendmode != NLASTRIP_EXTEND_NOTHING) {
|
2012-05-12 16:11:34 +00:00
|
|
|
estrip = strip;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2012-05-12 16:11:34 +00:00
|
|
|
side = NES_TIME_AFTER;
|
2009-05-03 11:46:57 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* if time occurred after current strip... */
|
|
|
|
|
if (ctime > strip->end) {
|
|
|
|
|
/* only if this is the last strip should we do anything, and only if that is being held */
|
2009-07-06 03:44:44 +00:00
|
|
|
if (strip == strips->last) {
|
2019-04-22 09:39:35 +10:00
|
|
|
if (strip->extendmode != NLASTRIP_EXTEND_NOTHING) {
|
2012-05-12 16:11:34 +00:00
|
|
|
estrip = strip;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-05-12 16:11:34 +00:00
|
|
|
side = NES_TIME_AFTER;
|
2009-05-03 11:46:57 +00:00
|
|
|
break;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* otherwise, skip... as the 'before' case will catch it more elegantly! */
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* check if a valid strip was found
|
2018-11-14 12:53:15 +11:00
|
|
|
* - must not be muted (i.e. will have contribution
|
2009-05-03 11:46:57 +00:00
|
|
|
*/
|
2023-07-17 10:46:26 +02:00
|
|
|
if ((estrip == nullptr) || (estrip->flag & NLASTRIP_FLAG_MUTED)) {
|
|
|
|
|
return nullptr;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-06-07 07:04:31 +00:00
|
|
|
/* if ctime was not within the boundaries of the strip, clamp! */
|
|
|
|
|
switch (side) {
|
|
|
|
|
case NES_TIME_BEFORE: /* extend first frame only */
|
2012-05-12 16:11:34 +00:00
|
|
|
ctime = estrip->start;
|
2009-06-07 07:04:31 +00:00
|
|
|
break;
|
|
|
|
|
case NES_TIME_AFTER: /* extend last frame only */
|
2012-05-12 16:11:34 +00:00
|
|
|
ctime = estrip->end;
|
2009-06-07 07:04:31 +00:00
|
|
|
break;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* evaluate strip's evaluation controls
|
2018-11-14 12:53:15 +11:00
|
|
|
* - skip if no influence (i.e. same effect as muting the strip)
|
|
|
|
|
* - negative influence is not supported yet... how would that be defined?
|
2009-05-03 11:46:57 +00:00
|
|
|
*/
|
2019-04-27 12:07:07 +10:00
|
|
|
/* TODO: this sounds a bit hacky having a few isolated F-Curves
|
|
|
|
|
* stuck on some data it operates on... */
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
AnimationEvalContext clamped_eval_context = BKE_animsys_eval_context_construct_at(
|
|
|
|
|
anim_eval_context, ctime);
|
|
|
|
|
nlastrip_evaluate_controls(estrip, &clamped_eval_context, flush_to_original);
|
2019-04-22 09:39:35 +10:00
|
|
|
if (estrip->influence <= 0.0f) {
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-06-19 04:45:56 +00:00
|
|
|
/* check if strip has valid data to evaluate,
|
|
|
|
|
* and/or perform any additional type-specific actions
|
|
|
|
|
*/
|
2009-05-03 11:46:57 +00:00
|
|
|
switch (estrip->type) {
|
2023-07-17 10:46:26 +02:00
|
|
|
case NLASTRIP_TYPE_CLIP: /* clip must have some action to evaluate */
|
|
|
|
|
if (estrip->act == nullptr) {
|
|
|
|
|
return nullptr;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2009-05-03 11:46:57 +00:00
|
|
|
break;
|
2023-08-09 11:17:04 +10:00
|
|
|
/* There must be strips to transition from and to (i.e. `prev` and `next` required). */
|
|
|
|
|
case NLASTRIP_TYPE_TRANSITION:
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, estrip->prev, estrip->next)) {
|
|
|
|
|
return nullptr;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-06-19 04:45:56 +00:00
|
|
|
/* evaluate controls for the relevant extents of the bordering strips... */
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
AnimationEvalContext start_eval_context = BKE_animsys_eval_context_construct_at(
|
|
|
|
|
anim_eval_context, estrip->start);
|
|
|
|
|
AnimationEvalContext end_eval_context = BKE_animsys_eval_context_construct_at(
|
|
|
|
|
anim_eval_context, estrip->end);
|
|
|
|
|
nlastrip_evaluate_controls(estrip->prev, &start_eval_context, flush_to_original);
|
|
|
|
|
nlastrip_evaluate_controls(estrip->next, &end_eval_context, flush_to_original);
|
2009-05-03 11:46:57 +00:00
|
|
|
break;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* add to list of strips we need to evaluate */
|
2023-07-17 10:46:26 +02:00
|
|
|
nes = static_cast<NlaEvalStrip *>(MEM_callocN(sizeof(NlaEvalStrip), "NlaEvalStrip"));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-05-12 16:11:34 +00:00
|
|
|
nes->strip = estrip;
|
|
|
|
|
nes->strip_mode = side;
|
|
|
|
|
nes->track_index = index;
|
|
|
|
|
nes->strip_time = estrip->strip_time;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (list) {
|
2009-07-07 11:37:33 +00:00
|
|
|
BLI_addtail(list, nes);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
return nes;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
static NlaEvalStrip *nlastrips_ctime_get_strip_single(
|
|
|
|
|
ListBase *dst_list,
|
|
|
|
|
NlaStrip *single_strip,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
const bool flush_to_original)
|
|
|
|
|
{
|
|
|
|
|
ListBase single_tracks_list;
|
|
|
|
|
single_tracks_list.first = single_tracks_list.last = single_strip;
|
|
|
|
|
|
|
|
|
|
return nlastrips_ctime_get_strip(
|
|
|
|
|
dst_list, &single_tracks_list, -1, anim_eval_context, flush_to_original);
|
|
|
|
|
}
|
|
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* ---------------------- */
|
|
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Initialize a valid mask, allocating memory if necessary. */
|
|
|
|
|
static void nlavalidmask_init(NlaValidMask *mask, int bits)
|
2009-05-16 01:00:41 +00:00
|
|
|
{
|
2018-12-15 16:09:27 +03:00
|
|
|
if (BLI_BITMAP_SIZE(bits) > sizeof(mask->buffer)) {
|
|
|
|
|
mask->ptr = BLI_BITMAP_NEW(bits, "NlaValidMask");
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
mask->ptr = mask->buffer;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Free allocated memory for the mask. */
|
|
|
|
|
static void nlavalidmask_free(NlaValidMask *mask)
|
|
|
|
|
{
|
|
|
|
|
if (mask->ptr != mask->buffer) {
|
|
|
|
|
MEM_freeN(mask->ptr);
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* ---------------------- */
|
|
|
|
|
|
|
|
|
|
/* Hashing functions for NlaEvalChannelKey. */
|
|
|
|
|
static uint nlaevalchan_keyhash(const void *ptr)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
const NlaEvalChannelKey *key = static_cast<const NlaEvalChannelKey *>(ptr);
|
2018-12-15 16:09:27 +03:00
|
|
|
uint hash = BLI_ghashutil_ptrhash(key->ptr.data);
|
|
|
|
|
return hash ^ BLI_ghashutil_ptrhash(key->prop);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool nlaevalchan_keycmp(const void *a, const void *b)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
const NlaEvalChannelKey *A = static_cast<const NlaEvalChannelKey *>(a);
|
|
|
|
|
const NlaEvalChannelKey *B = static_cast<const NlaEvalChannelKey *>(b);
|
2018-12-15 16:09:27 +03:00
|
|
|
|
2019-01-05 19:55:25 +11:00
|
|
|
return ((A->ptr.data != B->ptr.data) || (A->prop != B->prop));
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ---------------------- */
|
|
|
|
|
|
|
|
|
|
/* Allocate a new blending value snapshot for the channel. */
|
|
|
|
|
static NlaEvalChannelSnapshot *nlaevalchan_snapshot_new(NlaEvalChannel *nec)
|
|
|
|
|
{
|
|
|
|
|
int length = nec->base_snapshot.length;
|
|
|
|
|
|
|
|
|
|
size_t byte_size = sizeof(NlaEvalChannelSnapshot) + sizeof(float) * length;
|
2023-07-17 10:46:26 +02:00
|
|
|
NlaEvalChannelSnapshot *nec_snapshot = static_cast<NlaEvalChannelSnapshot *>(
|
|
|
|
|
MEM_callocN(byte_size, "NlaEvalChannelSnapshot"));
|
2018-12-15 16:09:27 +03:00
|
|
|
|
|
|
|
|
nec_snapshot->channel = nec;
|
|
|
|
|
nec_snapshot->length = length;
|
2021-02-16 23:58:29 -05:00
|
|
|
nlavalidmask_init(&nec_snapshot->blend_domain, length);
|
2021-05-11 16:04:18 -04:00
|
|
|
nlavalidmask_init(&nec_snapshot->remap_domain, length);
|
2018-12-15 16:09:27 +03:00
|
|
|
|
|
|
|
|
return nec_snapshot;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Free a channel's blending value snapshot. */
|
|
|
|
|
static void nlaevalchan_snapshot_free(NlaEvalChannelSnapshot *nec_snapshot)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(!nec_snapshot->is_base);
|
|
|
|
|
|
2021-02-16 23:58:29 -05:00
|
|
|
nlavalidmask_free(&nec_snapshot->blend_domain);
|
2021-05-11 16:04:18 -04:00
|
|
|
nlavalidmask_free(&nec_snapshot->remap_domain);
|
2018-12-15 16:09:27 +03:00
|
|
|
MEM_freeN(nec_snapshot);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Copy all data in the snapshot. */
|
|
|
|
|
static void nlaevalchan_snapshot_copy(NlaEvalChannelSnapshot *dst,
|
|
|
|
|
const NlaEvalChannelSnapshot *src)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(dst->channel == src->channel);
|
|
|
|
|
|
|
|
|
|
memcpy(dst->values, src->values, sizeof(float) * dst->length);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ---------------------- */
|
|
|
|
|
|
|
|
|
|
/* Initialize a blending state snapshot structure. */
|
|
|
|
|
static void nlaeval_snapshot_init(NlaEvalSnapshot *snapshot,
|
|
|
|
|
NlaEvalData *nlaeval,
|
|
|
|
|
NlaEvalSnapshot *base)
|
|
|
|
|
{
|
|
|
|
|
snapshot->base = base;
|
2023-11-07 16:33:19 +11:00
|
|
|
snapshot->size = std::max(16, nlaeval->num_channels);
|
2023-07-17 10:46:26 +02:00
|
|
|
snapshot->channels = static_cast<NlaEvalChannelSnapshot **>(
|
|
|
|
|
MEM_callocN(sizeof(*snapshot->channels) * snapshot->size, "NlaEvalSnapshot::channels"));
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Retrieve the individual channel snapshot. */
|
|
|
|
|
static NlaEvalChannelSnapshot *nlaeval_snapshot_get(NlaEvalSnapshot *snapshot, int index)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
return (index < snapshot->size) ? snapshot->channels[index] : nullptr;
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Ensure at least this number of slots exists. */
|
|
|
|
|
static void nlaeval_snapshot_ensure_size(NlaEvalSnapshot *snapshot, int size)
|
|
|
|
|
{
|
|
|
|
|
if (size > snapshot->size) {
|
|
|
|
|
snapshot->size *= 2;
|
|
|
|
|
CLAMP_MIN(snapshot->size, size);
|
|
|
|
|
CLAMP_MIN(snapshot->size, 16);
|
|
|
|
|
|
|
|
|
|
size_t byte_size = sizeof(*snapshot->channels) * snapshot->size;
|
2023-07-17 10:46:26 +02:00
|
|
|
snapshot->channels = static_cast<NlaEvalChannelSnapshot **>(
|
|
|
|
|
MEM_recallocN_id(snapshot->channels, byte_size, "NlaEvalSnapshot::channels"));
|
2009-05-16 01:00:41 +00:00
|
|
|
}
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Retrieve the address of a slot in the blending state snapshot for this channel (may realloc). */
|
|
|
|
|
static NlaEvalChannelSnapshot **nlaeval_snapshot_ensure_slot(NlaEvalSnapshot *snapshot,
|
|
|
|
|
NlaEvalChannel *nec)
|
|
|
|
|
{
|
|
|
|
|
nlaeval_snapshot_ensure_size(snapshot, nec->owner->num_channels);
|
|
|
|
|
return &snapshot->channels[nec->index];
|
2009-05-16 01:00:41 +00:00
|
|
|
}
|
|
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Retrieve the blending snapshot for the specified channel, with fallback to base. */
|
|
|
|
|
static NlaEvalChannelSnapshot *nlaeval_snapshot_find_channel(NlaEvalSnapshot *snapshot,
|
|
|
|
|
NlaEvalChannel *nec)
|
2013-07-01 13:57:00 +00:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
while (snapshot != nullptr) {
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalChannelSnapshot *nec_snapshot = nlaeval_snapshot_get(snapshot, nec->index);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (nec_snapshot != nullptr) {
|
2018-12-15 16:09:27 +03:00
|
|
|
return nec_snapshot;
|
|
|
|
|
}
|
|
|
|
|
snapshot = snapshot->base;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return &nec->base_snapshot;
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-27 12:07:07 +10:00
|
|
|
/* Retrieve or create the channel value snapshot, copying from the other snapshot
|
|
|
|
|
* (or default values) */
|
2018-12-15 16:09:27 +03:00
|
|
|
static NlaEvalChannelSnapshot *nlaeval_snapshot_ensure_channel(NlaEvalSnapshot *snapshot,
|
|
|
|
|
NlaEvalChannel *nec)
|
|
|
|
|
{
|
|
|
|
|
NlaEvalChannelSnapshot **slot = nlaeval_snapshot_ensure_slot(snapshot, nec);
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (*slot == nullptr) {
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalChannelSnapshot *base_snapshot, *nec_snapshot;
|
|
|
|
|
|
|
|
|
|
nec_snapshot = nlaevalchan_snapshot_new(nec);
|
|
|
|
|
base_snapshot = nlaeval_snapshot_find_channel(snapshot->base, nec);
|
|
|
|
|
|
|
|
|
|
nlaevalchan_snapshot_copy(nec_snapshot, base_snapshot);
|
|
|
|
|
|
|
|
|
|
*slot = nec_snapshot;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return *slot;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Free all memory owned by this blending snapshot structure. */
|
|
|
|
|
static void nlaeval_snapshot_free_data(NlaEvalSnapshot *snapshot)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
if (snapshot->channels != nullptr) {
|
2018-12-15 16:09:27 +03:00
|
|
|
for (int i = 0; i < snapshot->size; i++) {
|
|
|
|
|
NlaEvalChannelSnapshot *nec_snapshot = snapshot->channels[i];
|
2023-07-17 10:46:26 +02:00
|
|
|
if (nec_snapshot != nullptr) {
|
2018-12-15 16:09:27 +03:00
|
|
|
nlaevalchan_snapshot_free(nec_snapshot);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MEM_freeN(snapshot->channels);
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
snapshot->base = nullptr;
|
2018-12-15 16:09:27 +03:00
|
|
|
snapshot->size = 0;
|
2023-07-17 10:46:26 +02:00
|
|
|
snapshot->channels = nullptr;
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ---------------------- */
|
|
|
|
|
|
|
|
|
|
/* Free memory owned by this evaluation channel. */
|
|
|
|
|
static void nlaevalchan_free_data(NlaEvalChannel *nec)
|
|
|
|
|
{
|
2021-01-14 19:27:46 -05:00
|
|
|
nlavalidmask_free(&nec->domain);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Initialize a full NLA evaluation state structure. */
|
|
|
|
|
static void nlaeval_init(NlaEvalData *nlaeval)
|
|
|
|
|
{
|
|
|
|
|
memset(nlaeval, 0, sizeof(*nlaeval));
|
|
|
|
|
|
|
|
|
|
nlaeval->path_hash = BLI_ghash_str_new("NlaEvalData::path_hash");
|
|
|
|
|
nlaeval->key_hash = BLI_ghash_new(
|
|
|
|
|
nlaevalchan_keyhash, nlaevalchan_keycmp, "NlaEvalData::key_hash");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void nlaeval_free(NlaEvalData *nlaeval)
|
|
|
|
|
{
|
|
|
|
|
/* Delete base snapshot - its channels are part of NlaEvalChannel and shouldn't be freed. */
|
|
|
|
|
MEM_SAFE_FREE(nlaeval->base_snapshot.channels);
|
|
|
|
|
|
|
|
|
|
/* Delete result snapshot. */
|
|
|
|
|
nlaeval_snapshot_free_data(&nlaeval->eval_snapshot);
|
|
|
|
|
|
|
|
|
|
/* Delete channels. */
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (NlaEvalChannel *, nec, &nlaeval->channels) {
|
2018-12-15 16:09:27 +03:00
|
|
|
nlaevalchan_free_data(nec);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_freelistN(&nlaeval->channels);
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_ghash_free(nlaeval->path_hash, nullptr, nullptr);
|
|
|
|
|
BLI_ghash_free(nlaeval->key_hash, nullptr, nullptr);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ---------------------- */
|
|
|
|
|
|
2020-12-15 10:23:12 +11:00
|
|
|
static int nlaevalchan_validate_index(const NlaEvalChannel *nec, int index)
|
2018-12-15 16:09:27 +03:00
|
|
|
{
|
|
|
|
|
if (nec->is_array) {
|
|
|
|
|
if (index >= 0 && index < nec->base_snapshot.length) {
|
|
|
|
|
return index;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
return 0;
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
2020-12-14 17:04:31 -05:00
|
|
|
static bool nlaevalchan_validate_index_ex(const NlaEvalChannel *nec, const int array_index)
|
|
|
|
|
{
|
|
|
|
|
/** Although array_index comes from fcurve, that doesn't necessarily mean the property has that
|
|
|
|
|
* many elements. */
|
|
|
|
|
const int index = nlaevalchan_validate_index(nec, array_index);
|
|
|
|
|
|
|
|
|
|
if (index < 0) {
|
|
|
|
|
if (G.debug & G_DEBUG) {
|
|
|
|
|
ID *id = nec->key.ptr.owner_id;
|
|
|
|
|
CLOG_WARN(&LOG,
|
|
|
|
|
"Animation: Invalid array index. ID = '%s', '%s[%d]', array length is %d",
|
|
|
|
|
id ? (id->name + 2) : "<No ID>",
|
|
|
|
|
nec->rna_path,
|
|
|
|
|
array_index,
|
|
|
|
|
nec->base_snapshot.length);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-01 12:47:59 +10:00
|
|
|
/* Initialize default values for NlaEvalChannel from the property data. */
|
2018-12-15 16:09:27 +03:00
|
|
|
static void nlaevalchan_get_default_values(NlaEvalChannel *nec, float *r_values)
|
|
|
|
|
{
|
|
|
|
|
PointerRNA *ptr = &nec->key.ptr;
|
|
|
|
|
PropertyRNA *prop = nec->key.prop;
|
|
|
|
|
int length = nec->base_snapshot.length;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-23 18:43:01 +03:00
|
|
|
/* Use unit quaternion for quaternion properties. */
|
|
|
|
|
if (nec->mix_mode == NEC_MIX_QUATERNION) {
|
|
|
|
|
unit_qt(r_values);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
/* Use all zero for Axis-Angle properties. */
|
|
|
|
|
if (nec->mix_mode == NEC_MIX_AXIS_ANGLE) {
|
|
|
|
|
zero_v4(r_values);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* NOTE: while this doesn't work for all RNA properties as default values aren't in fact
|
|
|
|
|
* set properly for most of them, at least the common ones (which also happen to get used
|
2013-07-01 13:57:00 +00:00
|
|
|
* in NLA strips a lot, e.g. scale) are set correctly.
|
|
|
|
|
*/
|
2018-12-15 16:09:27 +03:00
|
|
|
if (RNA_property_array_check(prop)) {
|
|
|
|
|
BLI_assert(length == RNA_property_array_length(ptr, prop));
|
|
|
|
|
bool *tmp_bool;
|
|
|
|
|
int *tmp_int;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
switch (RNA_property_type(prop)) {
|
|
|
|
|
case PROP_BOOLEAN:
|
2023-07-17 10:46:26 +02:00
|
|
|
tmp_bool = static_cast<bool *>(MEM_malloc_arrayN(length, sizeof(*tmp_bool), __func__));
|
2018-12-15 16:09:27 +03:00
|
|
|
RNA_property_boolean_get_default_array(ptr, prop, tmp_bool);
|
|
|
|
|
for (int i = 0; i < length; i++) {
|
2023-07-18 14:18:07 +10:00
|
|
|
r_values[i] = float(tmp_bool[i]);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
MEM_freeN(tmp_bool);
|
|
|
|
|
break;
|
|
|
|
|
case PROP_INT:
|
2023-07-17 10:46:26 +02:00
|
|
|
tmp_int = static_cast<int *>(MEM_malloc_arrayN(length, sizeof(*tmp_int), __func__));
|
2018-12-15 16:09:27 +03:00
|
|
|
RNA_property_int_get_default_array(ptr, prop, tmp_int);
|
|
|
|
|
for (int i = 0; i < length; i++) {
|
2023-07-18 14:18:07 +10:00
|
|
|
r_values[i] = float(tmp_int[i]);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
MEM_freeN(tmp_int);
|
|
|
|
|
break;
|
|
|
|
|
case PROP_FLOAT:
|
|
|
|
|
RNA_property_float_get_default_array(ptr, prop, r_values);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
memset(r_values, 0, sizeof(float) * length);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BLI_assert(length == 1);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
switch (RNA_property_type(prop)) {
|
|
|
|
|
case PROP_BOOLEAN:
|
2023-07-18 14:18:07 +10:00
|
|
|
*r_values = float(RNA_property_boolean_get_default(ptr, prop));
|
2018-12-15 16:09:27 +03:00
|
|
|
break;
|
|
|
|
|
case PROP_INT:
|
2023-07-18 14:18:07 +10:00
|
|
|
*r_values = float(RNA_property_int_get_default(ptr, prop));
|
2018-12-15 16:09:27 +03:00
|
|
|
break;
|
|
|
|
|
case PROP_FLOAT:
|
|
|
|
|
*r_values = RNA_property_float_get_default(ptr, prop);
|
|
|
|
|
break;
|
|
|
|
|
case PROP_ENUM:
|
2023-07-18 14:18:07 +10:00
|
|
|
*r_values = float(RNA_property_enum_get_default(ptr, prop));
|
2018-12-15 16:09:27 +03:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
*r_values = 0.0f;
|
|
|
|
|
}
|
2013-07-01 13:57:00 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-23 18:43:01 +03:00
|
|
|
/* Ensure multiplicative properties aren't reset to 0. */
|
|
|
|
|
if (nec->mix_mode == NEC_MIX_MULTIPLY) {
|
|
|
|
|
for (int i = 0; i < length; i++) {
|
|
|
|
|
if (r_values[i] == 0.0f) {
|
|
|
|
|
r_values[i] = 1.0f;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static char nlaevalchan_detect_mix_mode(NlaEvalChannelKey *key, int length)
|
|
|
|
|
{
|
|
|
|
|
PropertySubType subtype = RNA_property_subtype(key->prop);
|
|
|
|
|
|
|
|
|
|
if (subtype == PROP_QUATERNION && length == 4) {
|
|
|
|
|
return NEC_MIX_QUATERNION;
|
|
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
if (subtype == PROP_AXISANGLE && length == 4) {
|
2018-12-23 18:43:01 +03:00
|
|
|
return NEC_MIX_AXIS_ANGLE;
|
|
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
if (RNA_property_flag(key->prop) & PROP_PROPORTIONAL) {
|
2018-12-23 18:43:01 +03:00
|
|
|
return NEC_MIX_MULTIPLY;
|
|
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
return NEC_MIX_ADD;
|
2013-07-01 13:57:00 +00:00
|
|
|
}
|
|
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Verify that an appropriate NlaEvalChannel for this property exists. */
|
|
|
|
|
static NlaEvalChannel *nlaevalchan_verify_key(NlaEvalData *nlaeval,
|
|
|
|
|
const char *path,
|
|
|
|
|
NlaEvalChannelKey *key)
|
2009-05-15 13:23:03 +00:00
|
|
|
{
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Look it up in the key hash. */
|
|
|
|
|
NlaEvalChannel **p_key_nec;
|
|
|
|
|
NlaEvalChannelKey **p_key;
|
2019-01-06 20:26:08 +11:00
|
|
|
bool found_key = BLI_ghash_ensure_p_ex(
|
|
|
|
|
nlaeval->key_hash, key, (void ***)&p_key, (void ***)&p_key_nec);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
if (found_key) {
|
|
|
|
|
return *p_key_nec;
|
2009-05-15 13:23:03 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Create the channel. */
|
|
|
|
|
bool is_array = RNA_property_array_check(key->prop);
|
|
|
|
|
int length = is_array ? RNA_property_array_length(&key->ptr, key->prop) : 1;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
NlaEvalChannel *nec = static_cast<NlaEvalChannel *>(
|
|
|
|
|
MEM_callocN(sizeof(NlaEvalChannel) + sizeof(float) * length, "NlaEvalChannel"));
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Initialize the channel. */
|
|
|
|
|
nec->rna_path = path;
|
|
|
|
|
nec->key = *key;
|
2018-11-07 19:47:22 +03:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
nec->owner = nlaeval;
|
|
|
|
|
nec->index = nlaeval->num_channels++;
|
|
|
|
|
nec->is_array = is_array;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-23 18:43:01 +03:00
|
|
|
nec->mix_mode = nlaevalchan_detect_mix_mode(key, length);
|
|
|
|
|
|
2021-01-14 19:27:46 -05:00
|
|
|
nlavalidmask_init(&nec->domain, length);
|
2018-12-15 16:09:27 +03:00
|
|
|
|
|
|
|
|
nec->base_snapshot.channel = nec;
|
|
|
|
|
nec->base_snapshot.length = length;
|
|
|
|
|
nec->base_snapshot.is_base = true;
|
|
|
|
|
|
|
|
|
|
nlaevalchan_get_default_values(nec, nec->base_snapshot.values);
|
|
|
|
|
|
|
|
|
|
/* Store channel in data structures. */
|
|
|
|
|
BLI_addtail(&nlaeval->channels, nec);
|
|
|
|
|
|
|
|
|
|
*nlaeval_snapshot_ensure_slot(&nlaeval->base_snapshot, nec) = &nec->base_snapshot;
|
|
|
|
|
|
|
|
|
|
*p_key_nec = nec;
|
|
|
|
|
*p_key = &nec->key;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-05-15 13:23:03 +00:00
|
|
|
return nec;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Verify that an appropriate NlaEvalChannel for this path exists. */
|
|
|
|
|
static NlaEvalChannel *nlaevalchan_verify(PointerRNA *ptr, NlaEvalData *nlaeval, const char *path)
|
2009-05-16 01:00:41 +00:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
if (path == nullptr) {
|
|
|
|
|
return nullptr;
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Lookup the path in the path based hash. */
|
|
|
|
|
NlaEvalChannel **p_path_nec;
|
2019-01-06 20:26:08 +11:00
|
|
|
bool found_path = BLI_ghash_ensure_p(nlaeval->path_hash, (void *)path, (void ***)&p_path_nec);
|
2018-12-15 16:09:27 +03:00
|
|
|
|
|
|
|
|
if (found_path) {
|
|
|
|
|
return *p_path_nec;
|
2014-03-03 16:34:10 +01:00
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
/* Cache nullptr result for now. */
|
|
|
|
|
*p_path_nec = nullptr;
|
2019-04-20 14:15:30 +03:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* Resolve the property and look it up in the key hash. */
|
|
|
|
|
NlaEvalChannelKey key;
|
|
|
|
|
|
|
|
|
|
if (!RNA_path_resolve_property(ptr, path, &key.ptr, &key.prop)) {
|
|
|
|
|
/* Report failure to resolve the path. */
|
|
|
|
|
if (G.debug & G_DEBUG) {
|
2019-02-01 12:44:19 +11:00
|
|
|
CLOG_WARN(&LOG,
|
|
|
|
|
"Animato: Invalid path. ID = '%s', '%s'",
|
2019-08-23 09:52:12 +02:00
|
|
|
(ptr->owner_id) ? (ptr->owner_id->name + 2) : "<No ID>",
|
2019-02-01 12:44:19 +11:00
|
|
|
path);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2019-04-20 14:15:30 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check that the property can be animated. */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ptr->owner_id != nullptr && !RNA_property_animateable(&key.ptr, key.prop)) {
|
|
|
|
|
return nullptr;
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalChannel *nec = nlaevalchan_verify_key(nlaeval, path, &key);
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (nec->rna_path == nullptr) {
|
2018-12-15 16:09:27 +03:00
|
|
|
nec->rna_path = path;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return *p_path_nec = nec;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
|
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
/* ---------------------- */
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/** \returns true if a solution exists and the output was written to. */
|
|
|
|
|
static bool nla_blend_get_inverted_lower_value(const int blendmode,
|
|
|
|
|
const float strip_value,
|
|
|
|
|
const float blended_value,
|
|
|
|
|
const float influence,
|
|
|
|
|
float *r_lower_value)
|
|
|
|
|
{
|
|
|
|
|
if (IS_EQF(influence, 0.0f)) {
|
|
|
|
|
*r_lower_value = blended_value;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (blendmode) {
|
2023-07-17 10:46:26 +02:00
|
|
|
case NLASTRIP_MODE_ADD: /* Simply subtract the scaled value on to the stack. */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
*r_lower_value = blended_value - (strip_value * influence);
|
|
|
|
|
return true;
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
case NLASTRIP_MODE_SUBTRACT: /* Simply add the scaled value from the stack. */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
*r_lower_value = blended_value + (strip_value * influence);
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
case NLASTRIP_MODE_MULTIPLY: {
|
|
|
|
|
/* Check for division by zero. */
|
|
|
|
|
const float denominator = (influence * strip_value + (1.0f - influence));
|
|
|
|
|
if (IS_EQF(denominator, 0.0f)) {
|
|
|
|
|
/* For 0/0, any r_lower_value is a solution. We'll just choose 1.
|
|
|
|
|
*
|
|
|
|
|
* Any r_lower_value is a solution. In this case, ideally we would insert redundant
|
|
|
|
|
* keyframes, those that don't change the fcurve's shape. Otherwise, we're likely messing
|
|
|
|
|
* up interpolation for the animator, requiring further cleanup on their part.
|
|
|
|
|
*/
|
|
|
|
|
if (IS_EQF(blended_value, 0.0f)) {
|
|
|
|
|
/* When denominator==0:
|
|
|
|
|
*
|
|
|
|
|
* denominator = (inf * strip_value + (1.0f - inf))
|
|
|
|
|
* 0 = inf * strip_value + (1-inf)
|
|
|
|
|
* -inf * strip_value = 1 - inf
|
|
|
|
|
* -strip_value = (1 - inf) / inf
|
|
|
|
|
* strip_value = (inf - 1) / inf
|
|
|
|
|
* strip_value = 1 - (1/inf)
|
|
|
|
|
*
|
|
|
|
|
* For blending, nla_blend_value(), this results in:
|
|
|
|
|
*
|
|
|
|
|
* blended_value = inf * (lower_value * strip_value) + (1 - inf) * lower_value;
|
|
|
|
|
* = inf * (lower_value * (1 - (1/inf))) + ...
|
|
|
|
|
* = inf * (1 - (1/inf)) * lower_value + ...
|
|
|
|
|
* = (inf - (inf/inf)) * lower_value + ...
|
|
|
|
|
* = -(inf - 1) * lower_value + (1 - inf) * lower_value;
|
|
|
|
|
* blended_value = 0
|
|
|
|
|
*
|
|
|
|
|
* Effectively, blended_value will equal 0 no matter what lower_value is. Put another
|
|
|
|
|
* way, when (blended_value==0 and denominator==0), then lower_value can be any value and
|
|
|
|
|
* blending will give us back blended_value=0. We have infinite solutions for this case.
|
|
|
|
|
*/
|
|
|
|
|
*r_lower_value = 1;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
/* No solution for division by zero. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
/* Math:
|
|
|
|
|
* blended_value = inf * (lower_value * strip_value) + (1 - inf) * lower_value
|
|
|
|
|
* = lower_value * (inf * strip_value + (1-inf))
|
|
|
|
|
* lower_value = blended_value / (inf * strip_value + (1-inf))
|
|
|
|
|
* lower_value = blended_value / denominator
|
|
|
|
|
*/
|
|
|
|
|
*r_lower_value = blended_value / denominator;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
case NLASTRIP_MODE_COMBINE:
|
|
|
|
|
BLI_assert_msg(0, "Use nla_combine_get_inverted_lower_value()");
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
case NLASTRIP_MODE_REPLACE:
|
|
|
|
|
|
|
|
|
|
/* No solution if lower strip has 0 influence. */
|
|
|
|
|
if (IS_EQF(influence, 1.0f)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Math:
|
|
|
|
|
*
|
|
|
|
|
* blended_value = lower_value * (1.0f - inf) + (strip_value * inf)
|
|
|
|
|
* blended_value - (strip_value * inf) = lower_value * (1.0f - inf)
|
|
|
|
|
* blended_value - (strip_value * inf) / (1.0f - inf) = lower_value
|
|
|
|
|
*
|
|
|
|
|
* lower_value = blended_value - (strip_value * inf) / (1.0f - inf)
|
|
|
|
|
*/
|
|
|
|
|
*r_lower_value = (blended_value - (strip_value * influence)) / (1.0f - influence);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_assert_msg(0, "invalid blend mode");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** \returns true if solution exists and output written to. */
|
|
|
|
|
static bool nla_combine_get_inverted_lower_value(const int mix_mode,
|
|
|
|
|
float base_value,
|
|
|
|
|
const float strip_value,
|
|
|
|
|
const float blended_value,
|
|
|
|
|
const float influence,
|
|
|
|
|
float *r_lower_value)
|
|
|
|
|
{
|
|
|
|
|
if (IS_EQF(influence, 0.0f)) {
|
|
|
|
|
*r_lower_value = blended_value;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Perform blending. */
|
|
|
|
|
switch (mix_mode) {
|
|
|
|
|
case NEC_MIX_ADD:
|
|
|
|
|
case NEC_MIX_AXIS_ANGLE:
|
|
|
|
|
*r_lower_value = blended_value - (strip_value - base_value) * influence;
|
|
|
|
|
return true;
|
2023-07-17 10:46:26 +02:00
|
|
|
case NEC_MIX_MULTIPLY: /* Division by zero. */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
if (IS_EQF(strip_value, 0.0f)) {
|
|
|
|
|
/* Resolve 0/0 to 1.
|
|
|
|
|
*
|
|
|
|
|
* Any r_lower_value is a solution. In this case, ideally we would insert redundant
|
|
|
|
|
* keyframes, those that don't change the fcurve's shape. Otherwise, we're likely messing
|
|
|
|
|
* up interpolation for the animator, requiring further cleanup on their part.
|
|
|
|
|
*/
|
|
|
|
|
if (IS_EQF(blended_value, 0.0f)) {
|
2023-09-03 21:35:03 +10:00
|
|
|
/* For blending, nla_combine_value(), when `strip_value == 0`:
|
|
|
|
|
* \code{.cc}
|
|
|
|
|
* blended_value = lower_value * powf(strip_value / base_value, infl);
|
|
|
|
|
* blended_value = lower_value * powf(0, infl);
|
|
|
|
|
* blended_value = lower_value * 0;
|
|
|
|
|
* blended_value = 0;
|
|
|
|
|
* \endcode
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
*
|
|
|
|
|
* Effectively, blended_value will equal 0 no matter what lower_value is. Put another
|
|
|
|
|
* way, when (blended_value==0 and strip_value==0), then lower_value can be any value and
|
|
|
|
|
* blending will give us back blended_value=0. We have infinite solutions for this case.
|
|
|
|
|
*/
|
|
|
|
|
*r_lower_value = 1.0f;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
/* No solution. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (IS_EQF(base_value, 0.0f)) {
|
|
|
|
|
base_value = 1.0f;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*r_lower_value = blended_value / powf(strip_value / base_value, influence);
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
case NEC_MIX_QUATERNION:
|
|
|
|
|
BLI_assert_msg(0, "Use nla_combine_quaternion_get_inverted_lower_values()");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_assert_msg(0, "Mixmode not implemented");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void nla_combine_quaternion_get_inverted_lower_values(const float strip_values[4],
|
|
|
|
|
const float blended_values[4],
|
|
|
|
|
const float influence,
|
|
|
|
|
float r_lower_value[4])
|
|
|
|
|
{
|
|
|
|
|
if (IS_EQF(influence, 0.0f)) {
|
|
|
|
|
normalize_qt_qt(r_lower_value, blended_values);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* blended_value = lower_values @ strip_values^infl
|
|
|
|
|
* blended_value @ inv(strip_values^inf) = lower_values
|
|
|
|
|
*
|
|
|
|
|
* Returns: lower_values = blended_value @ inv(strip_values^inf) */
|
|
|
|
|
float tmp_strip_values[4], tmp_blended[4];
|
|
|
|
|
|
|
|
|
|
normalize_qt_qt(tmp_strip_values, strip_values);
|
|
|
|
|
normalize_qt_qt(tmp_blended, blended_values);
|
|
|
|
|
|
|
|
|
|
pow_qt_fl_normalized(tmp_strip_values, influence);
|
|
|
|
|
invert_qt_normalized(tmp_strip_values);
|
|
|
|
|
|
|
|
|
|
mul_qt_qtqt(r_lower_value, tmp_blended, tmp_strip_values);
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
/* Blend the lower nla stack value and upper strip value of a channel according to mode and
|
|
|
|
|
* influence. */
|
|
|
|
|
static float nla_blend_value(const int blendmode,
|
|
|
|
|
const float lower_value,
|
|
|
|
|
const float strip_value,
|
|
|
|
|
const float influence)
|
2018-11-12 19:41:53 +03:00
|
|
|
{
|
2020-09-19 14:18:05 +10:00
|
|
|
/* Optimization: no need to try applying if there is no influence. */
|
2020-12-21 13:58:36 -05:00
|
|
|
if (IS_EQF(influence, 0.0f)) {
|
|
|
|
|
return lower_value;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
/* Perform blending. */
|
2009-06-19 04:45:56 +00:00
|
|
|
switch (blendmode) {
|
2023-07-17 10:46:26 +02:00
|
|
|
case NLASTRIP_MODE_ADD: /* Simply add the scaled value on to the stack. */
|
2020-12-21 13:58:36 -05:00
|
|
|
return lower_value + (strip_value * influence);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
case NLASTRIP_MODE_SUBTRACT: /* Simply subtract the scaled value from the stack. */
|
2020-12-21 13:58:36 -05:00
|
|
|
return lower_value - (strip_value * influence);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
case NLASTRIP_MODE_MULTIPLY: /* Multiply the scaled value with the stack. */
|
2020-12-21 13:58:36 -05:00
|
|
|
return influence * (lower_value * strip_value) + (1 - influence) * lower_value;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-23 18:43:01 +03:00
|
|
|
case NLASTRIP_MODE_COMBINE:
|
2021-07-15 18:23:28 +10:00
|
|
|
BLI_assert_msg(0, "combine mode");
|
2018-12-23 18:43:01 +03:00
|
|
|
ATTR_FALLTHROUGH;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
default: /* TODO: Do we really want to blend by default? it seems more uses might prefer add...
|
|
|
|
|
*/
|
2023-09-14 13:25:24 +10:00
|
|
|
/* Do linear interpolation. The influence of the accumulated data
|
|
|
|
|
* (elsewhere, that is called `dstwegiht`) is 1 - influence,
|
|
|
|
|
* since the strip's influence is `srcweight`. */
|
2020-12-21 13:58:36 -05:00
|
|
|
return lower_value * (1.0f - influence) + (strip_value * influence);
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
/* Blend the lower nla stack value and upper strip value of a channel according to mode and
|
|
|
|
|
* influence. */
|
|
|
|
|
static float nla_combine_value(const int mix_mode,
|
|
|
|
|
float base_value,
|
|
|
|
|
const float lower_value,
|
|
|
|
|
const float strip_value,
|
|
|
|
|
const float influence)
|
2018-12-23 18:43:01 +03:00
|
|
|
{
|
2020-12-21 13:58:36 -05:00
|
|
|
/* Optimization: No need to try applying if there is no influence. */
|
|
|
|
|
if (IS_EQF(influence, 0.0f)) {
|
|
|
|
|
return lower_value;
|
2018-12-23 18:43:01 +03:00
|
|
|
}
|
|
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
/* Perform blending */
|
2018-12-23 18:43:01 +03:00
|
|
|
switch (mix_mode) {
|
|
|
|
|
case NEC_MIX_ADD:
|
|
|
|
|
case NEC_MIX_AXIS_ANGLE:
|
2020-12-21 13:58:36 -05:00
|
|
|
return lower_value + (strip_value - base_value) * influence;
|
2018-12-23 18:43:01 +03:00
|
|
|
|
|
|
|
|
case NEC_MIX_MULTIPLY:
|
2020-12-14 17:08:51 -05:00
|
|
|
if (IS_EQF(base_value, 0.0f)) {
|
2018-12-23 18:43:01 +03:00
|
|
|
base_value = 1.0f;
|
|
|
|
|
}
|
2020-12-21 13:58:36 -05:00
|
|
|
return lower_value * powf(strip_value / base_value, influence);
|
2018-12-23 18:43:01 +03:00
|
|
|
|
|
|
|
|
default:
|
2021-07-15 18:23:28 +10:00
|
|
|
BLI_assert_msg(0, "invalid mix mode");
|
2020-12-21 13:58:36 -05:00
|
|
|
return lower_value;
|
2018-12-23 18:43:01 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
/** \returns true if solution exists and output is written to. */
|
|
|
|
|
static bool nla_blend_get_inverted_strip_value(const int blendmode,
|
|
|
|
|
const float lower_value,
|
|
|
|
|
const float blended_value,
|
|
|
|
|
const float influence,
|
|
|
|
|
float *r_strip_value)
|
2018-11-12 19:41:53 +03:00
|
|
|
{
|
2020-12-14 17:08:51 -05:00
|
|
|
/** No solution if strip had 0 influence. */
|
2020-12-15 10:23:12 +11:00
|
|
|
if (IS_EQF(influence, 0.0f)) {
|
2020-12-14 17:08:51 -05:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
switch (blendmode) {
|
2018-11-12 19:41:53 +03:00
|
|
|
case NLASTRIP_MODE_ADD:
|
2020-12-21 13:58:36 -05:00
|
|
|
*r_strip_value = (blended_value - lower_value) / influence;
|
2018-11-12 19:41:53 +03:00
|
|
|
return true;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-11-12 19:41:53 +03:00
|
|
|
case NLASTRIP_MODE_SUBTRACT:
|
2020-12-21 13:58:36 -05:00
|
|
|
*r_strip_value = (lower_value - blended_value) / influence;
|
2018-11-12 19:41:53 +03:00
|
|
|
return true;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-11-12 19:41:53 +03:00
|
|
|
case NLASTRIP_MODE_MULTIPLY:
|
2020-12-21 13:58:36 -05:00
|
|
|
if (IS_EQF(lower_value, 0.0f)) {
|
2018-11-12 19:41:53 +03:00
|
|
|
/* Resolve 0/0 to 1. */
|
2020-12-21 13:58:36 -05:00
|
|
|
if (IS_EQF(blended_value, 0.0f)) {
|
|
|
|
|
*r_strip_value = 1.0f;
|
2018-11-12 19:41:53 +03:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
/* Division by zero. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2020-12-21 13:58:36 -05:00
|
|
|
|
|
|
|
|
/** Math:
|
|
|
|
|
*
|
|
|
|
|
* blended_value = inf * (lower_value * strip_value) + (1 - inf) * lower_value
|
|
|
|
|
* blended_value - (1 - inf) * lower_value = inf * (lower_value * strip_value)
|
|
|
|
|
* (blended_value - (1 - inf) * lower_value) / (inf * lower_value) = strip_value
|
|
|
|
|
* (blended_value - lower_value + inf * lower_value) / (inf * lower_value) = strip_value
|
|
|
|
|
* ((blended_value - lower_value) / (inf * lower_value)) + 1 = strip_value
|
|
|
|
|
*
|
|
|
|
|
* strip_value = ((blended_value - lower_value) / (inf * lower_value)) + 1
|
|
|
|
|
*/
|
|
|
|
|
*r_strip_value = ((blended_value - lower_value) / (influence * lower_value)) + 1.0f;
|
|
|
|
|
return true;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-23 18:43:01 +03:00
|
|
|
case NLASTRIP_MODE_COMBINE:
|
2021-07-15 18:23:28 +10:00
|
|
|
BLI_assert_msg(0, "combine mode");
|
2018-12-23 18:43:01 +03:00
|
|
|
ATTR_FALLTHROUGH;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-11-12 19:41:53 +03:00
|
|
|
default:
|
2020-12-21 13:58:36 -05:00
|
|
|
|
|
|
|
|
/** Math:
|
|
|
|
|
*
|
|
|
|
|
* blended_value = lower_value * (1.0f - inf) + (strip_value * inf)
|
|
|
|
|
* blended_value - lower_value * (1.0f - inf) = (strip_value * inf)
|
|
|
|
|
* (blended_value - lower_value * (1.0f - inf)) / inf = strip_value
|
|
|
|
|
*
|
|
|
|
|
* strip_value = (blended_value - lower_value * (1.0f - inf)) / inf
|
|
|
|
|
*/
|
|
|
|
|
*r_strip_value = (blended_value - lower_value * (1.0f - influence)) / influence;
|
2018-11-12 19:41:53 +03:00
|
|
|
return true;
|
2009-05-16 01:00:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-24 15:56:58 +10:00
|
|
|
/** \returns true if solution exists and output is written to. */
|
2020-12-21 13:58:36 -05:00
|
|
|
static bool nla_combine_get_inverted_strip_value(const int mix_mode,
|
|
|
|
|
float base_value,
|
|
|
|
|
const float lower_value,
|
|
|
|
|
const float blended_value,
|
|
|
|
|
const float influence,
|
|
|
|
|
float *r_strip_value)
|
2018-12-23 18:43:01 +03:00
|
|
|
{
|
2020-12-14 17:08:51 -05:00
|
|
|
/* No solution if strip had no influence. */
|
2020-12-15 10:23:12 +11:00
|
|
|
if (IS_EQF(influence, 0.0f)) {
|
2020-12-14 17:08:51 -05:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-23 18:43:01 +03:00
|
|
|
switch (mix_mode) {
|
|
|
|
|
case NEC_MIX_ADD:
|
|
|
|
|
case NEC_MIX_AXIS_ANGLE:
|
2020-12-21 13:58:36 -05:00
|
|
|
*r_strip_value = base_value + (blended_value - lower_value) / influence;
|
2018-12-23 18:43:01 +03:00
|
|
|
return true;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-23 18:43:01 +03:00
|
|
|
case NEC_MIX_MULTIPLY:
|
2020-12-14 17:08:51 -05:00
|
|
|
if (IS_EQF(base_value, 0.0f)) {
|
2018-12-23 18:43:01 +03:00
|
|
|
base_value = 1.0f;
|
|
|
|
|
}
|
2021-02-05 19:07:03 -08:00
|
|
|
/* Division by zero. */
|
2020-12-21 13:58:36 -05:00
|
|
|
if (IS_EQF(lower_value, 0.0f)) {
|
2018-12-23 18:43:01 +03:00
|
|
|
/* Resolve 0/0 to 1. */
|
2020-12-21 13:58:36 -05:00
|
|
|
if (IS_EQF(blended_value, 0.0f)) {
|
|
|
|
|
*r_strip_value = base_value;
|
2018-12-23 18:43:01 +03:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
/* Division by zero. */
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2020-07-03 18:04:40 +02:00
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
*r_strip_value = base_value * powf(blended_value / lower_value, 1.0f / influence);
|
2020-07-03 18:04:40 +02:00
|
|
|
return true;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-23 18:43:01 +03:00
|
|
|
default:
|
2021-07-15 18:23:28 +10:00
|
|
|
BLI_assert_msg(0, "invalid mix mode");
|
2018-12-23 18:43:01 +03:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-09 18:47:10 +10:00
|
|
|
/**
|
|
|
|
|
* Accumulate quaternion channels for Combine mode according to influence.
|
|
|
|
|
* \returns `blended_value = lower_values @ strip_values^infl`
|
2020-12-21 13:58:36 -05:00
|
|
|
*/
|
|
|
|
|
static void nla_combine_quaternion(const float lower_values[4],
|
|
|
|
|
const float strip_values[4],
|
|
|
|
|
const float influence,
|
|
|
|
|
float r_blended_value[4])
|
2018-12-23 18:43:01 +03:00
|
|
|
{
|
2020-12-21 13:58:36 -05:00
|
|
|
float tmp_lower[4], tmp_strip_values[4];
|
2018-12-23 18:43:01 +03:00
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
normalize_qt_qt(tmp_lower, lower_values);
|
|
|
|
|
normalize_qt_qt(tmp_strip_values, strip_values);
|
2018-12-23 18:43:01 +03:00
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
pow_qt_fl_normalized(tmp_strip_values, influence);
|
|
|
|
|
mul_qt_qtqt(r_blended_value, tmp_lower, tmp_strip_values);
|
2018-12-23 18:43:01 +03:00
|
|
|
}
|
|
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
/** \returns true if solution exists and output written to. */
|
|
|
|
|
static bool nla_combine_quaternion_get_inverted_strip_values(const float lower_values[4],
|
|
|
|
|
const float blended_values[4],
|
|
|
|
|
const float influence,
|
|
|
|
|
float r_strip_values[4])
|
2018-12-23 18:43:01 +03:00
|
|
|
{
|
2020-12-21 13:58:36 -05:00
|
|
|
/* blended_value = lower_values @ r_strip_values^infl
|
|
|
|
|
* inv(lower_values) @ blended_value = r_strip_values^infl
|
|
|
|
|
* (inv(lower_values) @ blended_value) ^ (1/inf) = r_strip_values
|
|
|
|
|
*
|
|
|
|
|
* Returns: r_strip_values = (inv(lower_values) @ blended_value) ^ (1/inf) */
|
2020-12-15 10:23:12 +11:00
|
|
|
if (IS_EQF(influence, 0.0f)) {
|
2020-12-14 17:08:51 -05:00
|
|
|
return false;
|
|
|
|
|
}
|
2020-12-21 13:58:36 -05:00
|
|
|
float tmp_lower[4], tmp_blended[4];
|
2018-12-23 18:43:01 +03:00
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
normalize_qt_qt(tmp_lower, lower_values);
|
|
|
|
|
normalize_qt_qt(tmp_blended, blended_values);
|
|
|
|
|
invert_qt_normalized(tmp_lower);
|
2018-12-23 18:43:01 +03:00
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
mul_qt_qtqt(r_strip_values, tmp_lower, tmp_blended);
|
|
|
|
|
pow_qt_fl_normalized(r_strip_values, 1.0f / influence);
|
2020-12-14 17:08:51 -05:00
|
|
|
|
|
|
|
|
return true;
|
2018-12-23 18:43:01 +03:00
|
|
|
}
|
|
|
|
|
|
2021-05-11 16:04:18 -04:00
|
|
|
/* ---------------------- */
|
|
|
|
|
|
|
|
|
|
/* Assert necs and necs->channel is nonNull. */
|
|
|
|
|
static void nlaevalchan_assert_nonNull(NlaEvalChannelSnapshot *necs)
|
|
|
|
|
{
|
|
|
|
|
UNUSED_VARS_NDEBUG(necs);
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_assert(necs != nullptr && necs->channel != nullptr);
|
2021-05-11 16:04:18 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Assert that the channels given can be blended or combined together. */
|
|
|
|
|
static void nlaevalchan_assert_blendOrcombine_compatible(NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs)
|
|
|
|
|
{
|
|
|
|
|
UNUSED_VARS_NDEBUG(lower_necs, upper_necs, blended_necs);
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_assert(!ELEM(nullptr, lower_necs, blended_necs));
|
|
|
|
|
BLI_assert(upper_necs == nullptr || lower_necs->length == upper_necs->length);
|
2021-05-11 16:04:18 -04:00
|
|
|
BLI_assert(lower_necs->length == blended_necs->length);
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-20 09:16:24 +10:00
|
|
|
/**
|
|
|
|
|
* Check each remap domain of blended values individually in case animator had a non-combine NLA
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
* strip with a subset of quaternion channels and remapping through any of them failed and thus
|
|
|
|
|
* potentially has undefined values.
|
|
|
|
|
*
|
2022-04-20 09:16:24 +10:00
|
|
|
* \returns true if case occurred and handled. Returns false if case didn't occur.
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
*/
|
|
|
|
|
static bool nlaevalchan_combine_quaternion_handle_undefined_blend_values(
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs, NlaEvalChannelSnapshot *upper_or_lower_necs)
|
|
|
|
|
{
|
|
|
|
|
for (int j = 0; j < 4; j++) {
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(blended_necs->remap_domain.ptr, j)) {
|
|
|
|
|
BLI_bitmap_set_all(upper_or_lower_necs->remap_domain.ptr, false, 4);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-11 16:04:18 -04:00
|
|
|
/* Assert that the channels given can be blended or combined together as a quaternion. */
|
|
|
|
|
static void nlaevalchan_assert_blendOrcombine_compatible_quaternion(
|
|
|
|
|
NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible(lower_necs, upper_necs, blended_necs);
|
|
|
|
|
BLI_assert(lower_necs->length == 4);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void nlaevalchan_copy_values(NlaEvalChannelSnapshot *dst, NlaEvalChannelSnapshot *src)
|
|
|
|
|
{
|
|
|
|
|
memcpy(dst->values, src->values, src->length * sizeof(float));
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-20 09:16:24 +10:00
|
|
|
/**
|
2023-07-17 10:46:26 +02:00
|
|
|
* Copies from lower necs to blended necs if upper necs is nullptr or has zero influence.
|
2022-04-20 09:16:24 +10:00
|
|
|
* \return true if copied.
|
|
|
|
|
*/
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
static bool nlaevalchan_blendOrcombine_try_copy_from_lower(NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_blended_necs)
|
2021-05-11 16:04:18 -04:00
|
|
|
{
|
|
|
|
|
const bool has_influence = !IS_EQF(upper_influence, 0.0f);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (upper_necs != nullptr && has_influence) {
|
2021-05-11 16:04:18 -04:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nlaevalchan_copy_values(r_blended_necs, lower_necs);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-20 09:16:24 +10:00
|
|
|
/**
|
2023-07-17 10:46:26 +02:00
|
|
|
* Copies to lower necs from blended necs if upper necs is nullptr or has zero influence. If
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
* successful, copies blended_necs remap domains to lower_necs.
|
2021-05-11 16:04:18 -04:00
|
|
|
*
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
* Does not check upper value blend domains.
|
|
|
|
|
*
|
2022-04-20 09:16:24 +10:00
|
|
|
* \return true if copied.
|
|
|
|
|
*/
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
static bool nlaevalchan_blendOrcombine_try_copy_to_lower(NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_lower_necs)
|
|
|
|
|
{
|
|
|
|
|
const bool has_influence = !IS_EQF(upper_influence, 0.0f);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (upper_necs != nullptr && has_influence) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nlaevalchan_copy_values(r_lower_necs, blended_necs);
|
|
|
|
|
|
|
|
|
|
/* Must copy remap domain to handle case where some blended values are out of domain. */
|
|
|
|
|
BLI_bitmap_copy_all(
|
|
|
|
|
r_lower_necs->remap_domain.ptr, blended_necs->remap_domain.ptr, r_lower_necs->length);
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-20 09:16:24 +10:00
|
|
|
/**
|
|
|
|
|
* Based on blendmode, blend lower necs with upper necs into blended necs.
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
*
|
|
|
|
|
* Each upper value's blend domain determines whether to blend or to copy directly
|
|
|
|
|
* from lower.
|
2021-05-11 16:04:18 -04:00
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_blend_value(NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const int upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_blended_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible(lower_necs, upper_necs, r_blended_necs);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
if (nlaevalchan_blendOrcombine_try_copy_from_lower(
|
2021-05-11 16:04:18 -04:00
|
|
|
lower_necs, upper_necs, upper_influence, r_blended_necs))
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const int length = lower_necs->length;
|
|
|
|
|
for (int j = 0; j < length; j++) {
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(upper_necs->blend_domain.ptr, j)) {
|
|
|
|
|
r_blended_necs->values[j] = lower_necs->values[j];
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
r_blended_necs->values[j] = nla_blend_value(
|
|
|
|
|
upper_blendmode, lower_necs->values[j], upper_necs->values[j], upper_influence);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-12 21:55:25 +10:00
|
|
|
/**
|
|
|
|
|
* Based on mix-mode, provided by one the necs,
|
|
|
|
|
* combines lower necs with upper necs into blended necs.
|
2021-05-11 16:04:18 -04:00
|
|
|
*
|
2021-05-12 21:55:25 +10:00
|
|
|
* Each upper value's blend domain determines whether to blend or to copy directly from lower.
|
2021-05-11 16:04:18 -04:00
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_combine_value(NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_blended_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible(lower_necs, upper_necs, r_blended_necs);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
if (nlaevalchan_blendOrcombine_try_copy_from_lower(
|
2021-05-11 16:04:18 -04:00
|
|
|
lower_necs, upper_necs, upper_influence, r_blended_necs))
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Assumes every base is the same. */
|
|
|
|
|
float *base_values = lower_necs->channel->base_snapshot.values;
|
|
|
|
|
const int length = lower_necs->length;
|
|
|
|
|
const char mix_mode = lower_necs->channel->mix_mode;
|
|
|
|
|
|
|
|
|
|
for (int j = 0; j < length; j++) {
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(upper_necs->blend_domain.ptr, j)) {
|
|
|
|
|
r_blended_necs->values[j] = lower_necs->values[j];
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
r_blended_necs->values[j] = nla_combine_value(
|
|
|
|
|
mix_mode, base_values[j], lower_necs->values[j], upper_necs->values[j], upper_influence);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-12 21:55:25 +10:00
|
|
|
/**
|
|
|
|
|
* Quaternion combines lower necs with upper necs into blended necs.
|
2021-05-11 16:04:18 -04:00
|
|
|
*
|
|
|
|
|
* Each upper value's blend domain determines whether to blend or to copy directly
|
|
|
|
|
* from lower.
|
|
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_combine_quaternion(NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_blended_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible_quaternion(lower_necs, upper_necs, r_blended_necs);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
if (nlaevalchan_blendOrcombine_try_copy_from_lower(
|
2021-05-11 16:04:18 -04:00
|
|
|
lower_necs, upper_necs, upper_influence, r_blended_necs))
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** No need to check per index. We limit to all or nothing combining for quaternions. */
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(upper_necs->blend_domain.ptr, 0)) {
|
|
|
|
|
nlaevalchan_copy_values(r_blended_necs, lower_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nla_combine_quaternion(
|
|
|
|
|
lower_necs->values, upper_necs->values, upper_influence, r_blended_necs->values);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-12 21:55:25 +10:00
|
|
|
/**
|
2021-05-14 17:35:22 +10:00
|
|
|
* Based on blend-mode and mix-mode, blend lower necs with upper necs into blended necs.
|
2021-05-11 16:04:18 -04:00
|
|
|
*
|
|
|
|
|
* Each upper value's blend domain determines whether to blend or to copy directly
|
|
|
|
|
* from lower.
|
|
|
|
|
*
|
2023-07-17 10:46:26 +02:00
|
|
|
* \param lower_necs: Never nullptr.
|
|
|
|
|
* \param upper_necs: Can be nullptr.
|
2021-05-11 16:04:18 -04:00
|
|
|
* \param upper_blendmode: Enum value in eNlaStrip_Blend_Mode.
|
|
|
|
|
* \param upper_influence: Value in range [0, 1].
|
2023-07-17 10:46:26 +02:00
|
|
|
* \param upper_necs: Never nullptr.
|
2021-05-11 16:04:18 -04:00
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_blendOrcombine(NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const int upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_blended_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_nonNull(r_blended_necs);
|
|
|
|
|
|
|
|
|
|
switch (upper_blendmode) {
|
|
|
|
|
case NLASTRIP_MODE_COMBINE: {
|
|
|
|
|
switch (r_blended_necs->channel->mix_mode) {
|
|
|
|
|
case NEC_MIX_QUATERNION: {
|
|
|
|
|
nlaevalchan_combine_quaternion(lower_necs, upper_necs, upper_influence, r_blended_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
case NEC_MIX_ADD:
|
|
|
|
|
case NEC_MIX_AXIS_ANGLE:
|
|
|
|
|
case NEC_MIX_MULTIPLY: {
|
|
|
|
|
nlaevalchan_combine_value(lower_necs, upper_necs, upper_influence, r_blended_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
default:
|
2021-07-22 00:46:46 +10:00
|
|
|
BLI_assert_msg(0, "Mix mode should've been handled");
|
2021-05-11 16:04:18 -04:00
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
case NLASTRIP_MODE_ADD:
|
|
|
|
|
case NLASTRIP_MODE_SUBTRACT:
|
|
|
|
|
case NLASTRIP_MODE_MULTIPLY:
|
|
|
|
|
case NLASTRIP_MODE_REPLACE: {
|
|
|
|
|
nlaevalchan_blend_value(
|
|
|
|
|
lower_necs, upper_necs, upper_blendmode, upper_influence, r_blended_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
default:
|
2021-07-22 00:46:46 +10:00
|
|
|
BLI_assert_msg(0, "Blend mode should've been handled");
|
2021-05-11 16:04:18 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-12 21:55:25 +10:00
|
|
|
/**
|
|
|
|
|
* Based on blend-mode, solve for the upper values such that when lower blended with upper then we
|
2021-05-11 16:04:18 -04:00
|
|
|
* get blended values as a result.
|
|
|
|
|
*
|
|
|
|
|
* Only processes blended values in the remap domain. Successfully remapped upper values are placed
|
|
|
|
|
* in the remap domain so caller knows which values are usable.
|
|
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_blend_value_get_inverted_upper_evalchan(
|
|
|
|
|
NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
const int upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_upper_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_nonNull(r_upper_necs);
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible(lower_necs, r_upper_necs, blended_necs);
|
|
|
|
|
|
|
|
|
|
const int length = lower_necs->length;
|
|
|
|
|
for (int j = 0; j < length; j++) {
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(blended_necs->remap_domain.ptr, j)) {
|
|
|
|
|
BLI_BITMAP_DISABLE(r_upper_necs->remap_domain.ptr, j);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const bool success = nla_blend_get_inverted_strip_value(upper_blendmode,
|
|
|
|
|
lower_necs->values[j],
|
|
|
|
|
blended_necs->values[j],
|
|
|
|
|
upper_influence,
|
|
|
|
|
&r_upper_necs->values[j]);
|
|
|
|
|
BLI_BITMAP_SET(r_upper_necs->remap_domain.ptr, j, success);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-12 21:55:25 +10:00
|
|
|
/**
|
2021-05-14 17:35:22 +10:00
|
|
|
* Based on mix-mode, solve for the upper values such that when lower combined with upper then we
|
2021-05-11 16:04:18 -04:00
|
|
|
* get blended values as a result.
|
|
|
|
|
*
|
|
|
|
|
* Only processes blended values in the remap domain. Successfully remapped upper values are placed
|
|
|
|
|
* in the remap domain so caller knows which values are usable.
|
|
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_combine_value_get_inverted_upper_evalchan(
|
|
|
|
|
NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_upper_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_nonNull(r_upper_necs);
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible(lower_necs, r_upper_necs, blended_necs);
|
|
|
|
|
|
|
|
|
|
/* Assumes every channel's base is the same. */
|
|
|
|
|
float *base_values = lower_necs->channel->base_snapshot.values;
|
|
|
|
|
const int length = lower_necs->length;
|
|
|
|
|
const char mix_mode = lower_necs->channel->mix_mode;
|
|
|
|
|
|
|
|
|
|
for (int j = 0; j < length; j++) {
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(blended_necs->remap_domain.ptr, j)) {
|
|
|
|
|
BLI_BITMAP_DISABLE(r_upper_necs->remap_domain.ptr, j);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const bool success = nla_combine_get_inverted_strip_value(mix_mode,
|
|
|
|
|
base_values[j],
|
|
|
|
|
lower_necs->values[j],
|
|
|
|
|
blended_necs->values[j],
|
|
|
|
|
upper_influence,
|
|
|
|
|
&r_upper_necs->values[j]);
|
|
|
|
|
|
|
|
|
|
BLI_BITMAP_SET(r_upper_necs->remap_domain.ptr, j, success);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-12 21:55:25 +10:00
|
|
|
/**
|
|
|
|
|
* Solve for the upper values such that when lower quaternion combined with upper then we get
|
2021-05-11 16:04:18 -04:00
|
|
|
* blended values as a result.
|
|
|
|
|
*
|
|
|
|
|
* All blended values must be in the remap domain. If successfully remapped, then all upper values
|
|
|
|
|
* are placed in the remap domain so caller knows the result is usable.
|
|
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_combine_quaternion_get_inverted_upper_evalchan(
|
|
|
|
|
NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_upper_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_nonNull(r_upper_necs);
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible_quaternion(lower_necs, r_upper_necs, blended_necs);
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
if (nlaevalchan_combine_quaternion_handle_undefined_blend_values(blended_necs, r_upper_necs)) {
|
|
|
|
|
return;
|
2021-05-11 16:04:18 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const bool success = nla_combine_quaternion_get_inverted_strip_values(
|
|
|
|
|
lower_necs->values, blended_necs->values, upper_influence, r_upper_necs->values);
|
|
|
|
|
|
|
|
|
|
BLI_bitmap_set_all(r_upper_necs->remap_domain.ptr, success, 4);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-12 21:55:25 +10:00
|
|
|
/**
|
|
|
|
|
* Based on blend-mode and mix mode, solve for the upper values such that when lower blended or
|
2021-05-11 16:04:18 -04:00
|
|
|
* combined with upper then we get blended values as a result.
|
|
|
|
|
*
|
|
|
|
|
* Only processes blended values in the remap domain. Successfully remapped upper values are placed
|
|
|
|
|
* in the remap domain so caller knows which values are usable.
|
|
|
|
|
*
|
2023-07-17 10:46:26 +02:00
|
|
|
* \param lower_necs: Never nullptr.
|
|
|
|
|
* \param blended_necs: Never nullptr.
|
2021-05-11 16:04:18 -04:00
|
|
|
* \param upper_blendmode: Enum value in eNlaStrip_Blend_Mode.
|
|
|
|
|
* \param upper_influence: Value in range [0, 1].
|
2023-07-17 10:46:26 +02:00
|
|
|
* \param r_upper_necs: Never nullptr.
|
2021-05-11 16:04:18 -04:00
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_blendOrcombine_get_inverted_upper_evalchan(
|
|
|
|
|
NlaEvalChannelSnapshot *lower_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
const int upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_upper_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_nonNull(r_upper_necs);
|
|
|
|
|
|
|
|
|
|
if (IS_EQF(upper_influence, 0.0f)) {
|
|
|
|
|
BLI_bitmap_set_all(r_upper_necs->remap_domain.ptr, false, r_upper_necs->length);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (upper_blendmode) {
|
|
|
|
|
case NLASTRIP_MODE_COMBINE: {
|
|
|
|
|
switch (r_upper_necs->channel->mix_mode) {
|
|
|
|
|
case NEC_MIX_QUATERNION: {
|
|
|
|
|
nlaevalchan_combine_quaternion_get_inverted_upper_evalchan(
|
|
|
|
|
lower_necs, blended_necs, upper_influence, r_upper_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
case NEC_MIX_ADD:
|
|
|
|
|
case NEC_MIX_AXIS_ANGLE:
|
|
|
|
|
case NEC_MIX_MULTIPLY: {
|
|
|
|
|
nlaevalchan_combine_value_get_inverted_upper_evalchan(
|
|
|
|
|
lower_necs, blended_necs, upper_influence, r_upper_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
default:
|
2021-07-22 00:46:46 +10:00
|
|
|
BLI_assert_msg(0, "Mix mode should've been handled");
|
2021-05-11 16:04:18 -04:00
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
case NLASTRIP_MODE_ADD:
|
|
|
|
|
case NLASTRIP_MODE_SUBTRACT:
|
|
|
|
|
case NLASTRIP_MODE_MULTIPLY:
|
|
|
|
|
case NLASTRIP_MODE_REPLACE: {
|
|
|
|
|
nlaevalchan_blend_value_get_inverted_upper_evalchan(
|
|
|
|
|
lower_necs, blended_necs, upper_blendmode, upper_influence, r_upper_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
default:
|
2021-07-22 00:46:46 +10:00
|
|
|
BLI_assert_msg(0, "Blend mode should've been handled");
|
2021-05-11 16:04:18 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
static void nlaevalchan_blend_value_get_inverted_lower_evalchan(
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const int upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_lower_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible(r_lower_necs, upper_necs, blended_necs);
|
|
|
|
|
|
|
|
|
|
if (nlaevalchan_blendOrcombine_try_copy_to_lower(
|
|
|
|
|
blended_necs, upper_necs, upper_influence, r_lower_necs))
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const int length = r_lower_necs->length;
|
|
|
|
|
|
|
|
|
|
for (int j = 0; j < length; j++) {
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(blended_necs->remap_domain.ptr, j)) {
|
|
|
|
|
BLI_BITMAP_DISABLE(r_lower_necs->remap_domain.ptr, j);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If upper value was not blended, then the blended value was directly copied from the lower
|
|
|
|
|
* value. */
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(upper_necs->blend_domain.ptr, j)) {
|
|
|
|
|
r_lower_necs->values[j] = blended_necs->values[j];
|
|
|
|
|
BLI_BITMAP_ENABLE(r_lower_necs->remap_domain.ptr, j);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const bool success = nla_blend_get_inverted_lower_value(upper_blendmode,
|
|
|
|
|
upper_necs->values[j],
|
|
|
|
|
blended_necs->values[j],
|
|
|
|
|
upper_influence,
|
|
|
|
|
&r_lower_necs->values[j]);
|
|
|
|
|
|
|
|
|
|
BLI_BITMAP_SET(r_lower_necs->remap_domain.ptr, j, success);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void nlaevalchan_combine_value_get_inverted_lower_evalchan(
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_lower_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible(r_lower_necs, upper_necs, blended_necs);
|
|
|
|
|
|
|
|
|
|
if (nlaevalchan_blendOrcombine_try_copy_to_lower(
|
|
|
|
|
blended_necs, upper_necs, upper_influence, r_lower_necs))
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
float *base_values = r_lower_necs->channel->base_snapshot.values;
|
|
|
|
|
const int mix_mode = r_lower_necs->channel->mix_mode;
|
|
|
|
|
const int length = r_lower_necs->length;
|
|
|
|
|
|
|
|
|
|
for (int j = 0; j < length; j++) {
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(blended_necs->remap_domain.ptr, j)) {
|
|
|
|
|
BLI_BITMAP_DISABLE(r_lower_necs->remap_domain.ptr, j);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If upper value was not blended, then the blended value was directly copied from the lower
|
|
|
|
|
* value. */
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(upper_necs->blend_domain.ptr, j)) {
|
|
|
|
|
r_lower_necs->values[j] = blended_necs->values[j];
|
|
|
|
|
BLI_BITMAP_ENABLE(r_lower_necs->remap_domain.ptr, j);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const bool success = nla_combine_get_inverted_lower_value(mix_mode,
|
|
|
|
|
base_values[j],
|
|
|
|
|
upper_necs->values[j],
|
|
|
|
|
blended_necs->values[j],
|
|
|
|
|
upper_influence,
|
|
|
|
|
&r_lower_necs->values[j]);
|
|
|
|
|
|
|
|
|
|
BLI_BITMAP_SET(r_lower_necs->remap_domain.ptr, j, success);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void nlaevalchan_combine_quaternion_get_inverted_lower_evalchan(
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_lower_necs)
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_blendOrcombine_compatible_quaternion(r_lower_necs, upper_necs, blended_necs);
|
|
|
|
|
|
|
|
|
|
if (nlaevalchan_combine_quaternion_handle_undefined_blend_values(blended_necs, r_lower_necs)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (nlaevalchan_blendOrcombine_try_copy_to_lower(
|
|
|
|
|
blended_necs, upper_necs, upper_influence, r_lower_necs))
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If upper value was not blended, then the blended value was directly copied from the lower
|
|
|
|
|
* value. */
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(upper_necs->blend_domain.ptr, 0)) {
|
|
|
|
|
memcpy(r_lower_necs->values, blended_necs->values, 4 * sizeof(float));
|
|
|
|
|
BLI_bitmap_set_all(r_lower_necs->remap_domain.ptr, true, 4);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nla_combine_quaternion_get_inverted_lower_values(
|
|
|
|
|
upper_necs->values, blended_necs->values, upper_influence, r_lower_necs->values);
|
|
|
|
|
|
|
|
|
|
BLI_bitmap_set_all(r_lower_necs->remap_domain.ptr, true, 4);
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-27 15:10:58 +10:00
|
|
|
/**
|
|
|
|
|
* Based on blendmode and mix mode, solve for the lower values such that when lower blended or
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
* combined with upper then we get blended values as a result.
|
|
|
|
|
*
|
|
|
|
|
* Only processes blended values in the remap domain. Successfully remapped lower values are placed
|
|
|
|
|
* in the remap domain so caller knows which values are usable.
|
|
|
|
|
*
|
2023-07-17 10:46:26 +02:00
|
|
|
* \param blended_necs: Never nullptr.
|
|
|
|
|
* \param upper_necs: Can be nullptr.
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
* \param upper_blendmode: Enum value in eNlaStrip_Blend_Mode.
|
|
|
|
|
* \param upper_influence: Value in range [0, 1].
|
2023-07-17 10:46:26 +02:00
|
|
|
* \param r_lower_necs: Never nullptr.
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
*/
|
|
|
|
|
static void nlaevalchan_blendOrCombine_get_inverted_lower_evalchan(
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs,
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs,
|
|
|
|
|
const int upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalChannelSnapshot *r_lower_necs)
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
nlaevalchan_assert_nonNull(r_lower_necs);
|
|
|
|
|
|
|
|
|
|
switch (upper_blendmode) {
|
|
|
|
|
case NLASTRIP_MODE_COMBINE: {
|
|
|
|
|
switch (r_lower_necs->channel->mix_mode) {
|
|
|
|
|
case NEC_MIX_QUATERNION: {
|
|
|
|
|
nlaevalchan_combine_quaternion_get_inverted_lower_evalchan(
|
|
|
|
|
blended_necs, upper_necs, upper_influence, r_lower_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
case NEC_MIX_ADD:
|
|
|
|
|
case NEC_MIX_AXIS_ANGLE:
|
|
|
|
|
case NEC_MIX_MULTIPLY: {
|
|
|
|
|
nlaevalchan_combine_value_get_inverted_lower_evalchan(
|
|
|
|
|
blended_necs, upper_necs, upper_influence, r_lower_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
BLI_assert_msg(0, "Mix mode should've been handled");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
case NLASTRIP_MODE_ADD:
|
|
|
|
|
case NLASTRIP_MODE_SUBTRACT:
|
|
|
|
|
case NLASTRIP_MODE_MULTIPLY:
|
|
|
|
|
case NLASTRIP_MODE_REPLACE: {
|
|
|
|
|
nlaevalchan_blend_value_get_inverted_lower_evalchan(
|
|
|
|
|
blended_necs, upper_necs, upper_blendmode, upper_influence, r_lower_necs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_assert_msg(0, "Blend mode should've been handled");
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* ---------------------- */
|
2019-04-27 12:07:07 +10:00
|
|
|
/* F-Modifier stack joining/separation utilities -
|
|
|
|
|
* should we generalize these for BLI_listbase.h interface? */
|
2009-07-07 12:17:06 +00:00
|
|
|
|
|
|
|
|
/* Temporarily join two lists of modifiers together, storing the result in a third list */
|
2012-05-12 16:11:34 +00:00
|
|
|
static void nlaeval_fmodifiers_join_stacks(ListBase *result, ListBase *list1, ListBase *list2)
|
2009-07-07 12:17:06 +00:00
|
|
|
{
|
|
|
|
|
FModifier *fcm1, *fcm2;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-06-24 15:56:58 +10:00
|
|
|
/* if list1 is invalid... */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, list1, list1->first)) {
|
2009-07-07 12:17:06 +00:00
|
|
|
if (list2 && list2->first) {
|
2012-05-12 16:11:34 +00:00
|
|
|
result->first = list2->first;
|
|
|
|
|
result->last = list2->last;
|
2009-07-07 12:17:06 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* if list 2 is invalid... */
|
2023-07-17 10:46:26 +02:00
|
|
|
else if (ELEM(nullptr, list2, list2->first)) {
|
2012-05-12 16:11:34 +00:00
|
|
|
result->first = list1->first;
|
|
|
|
|
result->last = list1->last;
|
2009-07-07 12:17:06 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2019-04-27 12:07:07 +10:00
|
|
|
/* list1 should be added first, and list2 second,
|
|
|
|
|
* with the endpoints of these being the endpoints for result
|
|
|
|
|
* - the original lists must be left unchanged though, as we need that fact for restoring.
|
2009-07-07 12:17:06 +00:00
|
|
|
*/
|
2012-05-12 16:11:34 +00:00
|
|
|
result->first = list1->first;
|
|
|
|
|
result->last = list2->last;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
fcm1 = static_cast<FModifier *>(list1->last);
|
|
|
|
|
fcm2 = static_cast<FModifier *>(list2->first);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-05-12 16:11:34 +00:00
|
|
|
fcm1->next = fcm2;
|
|
|
|
|
fcm2->prev = fcm1;
|
2009-07-07 12:17:06 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Split two temporary lists of modifiers */
|
2012-05-12 16:11:34 +00:00
|
|
|
static void nlaeval_fmodifiers_split_stacks(ListBase *list1, ListBase *list2)
|
2009-07-07 12:17:06 +00:00
|
|
|
{
|
|
|
|
|
FModifier *fcm1, *fcm2;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* if list1/2 is invalid... just skip */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, list1, list2)) {
|
2009-07-07 12:17:06 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, list1->first, list2->first)) {
|
2009-07-07 12:17:06 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* get endpoints */
|
2023-07-17 10:46:26 +02:00
|
|
|
fcm1 = static_cast<FModifier *>(list1->last);
|
|
|
|
|
fcm2 = static_cast<FModifier *>(list2->first);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* clear their links */
|
2023-07-17 10:46:26 +02:00
|
|
|
fcm1->next = nullptr;
|
|
|
|
|
fcm2->prev = nullptr;
|
2009-07-07 12:17:06 +00:00
|
|
|
}
|
|
|
|
|
|
2009-05-15 13:23:03 +00:00
|
|
|
/* ---------------------- */
|
|
|
|
|
|
2021-02-03 16:23:18 -05:00
|
|
|
/** Fills \a r_snapshot with the \a action's evaluated fcurve values with modifiers applied. */
|
|
|
|
|
static void nlasnapshot_from_action(PointerRNA *ptr,
|
|
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *modifiers,
|
|
|
|
|
bAction *action,
|
|
|
|
|
const float evaltime,
|
|
|
|
|
NlaEvalSnapshot *r_snapshot)
|
|
|
|
|
{
|
|
|
|
|
action_idcode_patch_check(ptr->owner_id, action);
|
|
|
|
|
|
|
|
|
|
/* Evaluate modifiers which modify time to evaluate the base curves at. */
|
|
|
|
|
FModifiersStackStorage storage;
|
|
|
|
|
storage.modifier_count = BLI_listbase_count(modifiers);
|
|
|
|
|
storage.size_per_modifier = evaluate_fmodifiers_storage_size_per_modifier(modifiers);
|
|
|
|
|
storage.buffer = alloca(storage.modifier_count * storage.size_per_modifier);
|
|
|
|
|
|
|
|
|
|
const float modified_evaltime = evaluate_time_fmodifiers(
|
2023-07-17 10:46:26 +02:00
|
|
|
&storage, modifiers, nullptr, 0.0f, evaltime);
|
2021-02-03 16:23:18 -05:00
|
|
|
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (FCurve *, fcu, &action->curves) {
|
2021-02-03 16:23:18 -05:00
|
|
|
if (!is_fcurve_evaluatable(fcu)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
NlaEvalChannel *nec = nlaevalchan_verify(ptr, channels, fcu->rna_path);
|
|
|
|
|
|
2021-02-05 14:18:12 -05:00
|
|
|
/* Invalid path or property cannot be animated. */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (nec == nullptr) {
|
2021-02-05 14:18:12 -05:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-03 16:23:18 -05:00
|
|
|
if (!nlaevalchan_validate_index_ex(nec, fcu->array_index)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-16 23:58:29 -05:00
|
|
|
NlaEvalChannelSnapshot *necs = nlaeval_snapshot_ensure_channel(r_snapshot, nec);
|
|
|
|
|
|
2021-02-03 16:23:18 -05:00
|
|
|
float value = evaluate_fcurve(fcu, modified_evaltime);
|
|
|
|
|
evaluate_value_fmodifiers(&storage, modifiers, fcu, &value, evaltime);
|
|
|
|
|
necs->values[fcu->array_index] = value;
|
2021-02-16 23:58:29 -05:00
|
|
|
|
|
|
|
|
if (nec->mix_mode == NEC_MIX_QUATERNION) {
|
|
|
|
|
BLI_bitmap_set_all(necs->blend_domain.ptr, true, 4);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BLI_BITMAP_ENABLE(necs->blend_domain.ptr, fcu->array_index);
|
|
|
|
|
}
|
2021-02-03 16:23:18 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-05-15 13:23:03 +00:00
|
|
|
/* evaluate action-clip strip */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
static void nlastrip_evaluate_actionclip(const int evaluation_mode,
|
|
|
|
|
PointerRNA *ptr,
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *modifiers,
|
|
|
|
|
NlaEvalStrip *nes,
|
|
|
|
|
NlaEvalSnapshot *snapshot)
|
2009-05-15 13:23:03 +00:00
|
|
|
{
|
2021-02-03 16:23:18 -05:00
|
|
|
|
2012-05-12 16:11:34 +00:00
|
|
|
NlaStrip *strip = nes->strip;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2011-04-19 13:01:50 +00:00
|
|
|
/* sanity checks for action */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (strip == nullptr) {
|
2011-04-19 13:01:50 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (strip->act == nullptr) {
|
2019-02-01 12:44:19 +11:00
|
|
|
CLOG_ERROR(&LOG, "NLA-Strip Eval Error: Strip '%s' has no Action", strip->name);
|
2011-04-19 13:01:50 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
ListBase tmp_modifiers = {nullptr, nullptr};
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* join this strip's modifiers to the parent's modifiers (own modifiers first) */
|
|
|
|
|
nlaeval_fmodifiers_join_stacks(&tmp_modifiers, &strip->modifiers, modifiers);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
switch (evaluation_mode) {
|
|
|
|
|
case STRIP_EVAL_BLEND: {
|
|
|
|
|
|
|
|
|
|
NlaEvalSnapshot strip_snapshot;
|
2023-07-17 10:46:26 +02:00
|
|
|
nlaeval_snapshot_init(&strip_snapshot, channels, nullptr);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
|
|
|
|
|
nlasnapshot_from_action(
|
|
|
|
|
ptr, channels, &tmp_modifiers, strip->act, strip->strip_time, &strip_snapshot);
|
|
|
|
|
nlasnapshot_blend(
|
|
|
|
|
channels, snapshot, &strip_snapshot, strip->blendmode, strip->influence, snapshot);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlaeval_snapshot_free_data(&strip_snapshot);
|
|
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case STRIP_EVAL_BLEND_GET_INVERTED_LOWER_SNAPSHOT: {
|
2018-06-17 17:05:51 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
NlaEvalSnapshot strip_snapshot;
|
2023-07-17 10:46:26 +02:00
|
|
|
nlaeval_snapshot_init(&strip_snapshot, channels, nullptr);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
|
|
|
|
|
nlasnapshot_from_action(
|
|
|
|
|
ptr, channels, &tmp_modifiers, strip->act, strip->strip_time, &strip_snapshot);
|
|
|
|
|
nlasnapshot_blend_get_inverted_lower_snapshot(
|
|
|
|
|
channels, snapshot, &strip_snapshot, strip->blendmode, strip->influence, snapshot);
|
|
|
|
|
|
|
|
|
|
nlaeval_snapshot_free_data(&strip_snapshot);
|
|
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case STRIP_EVAL_NOBLEND: {
|
|
|
|
|
nlasnapshot_from_action(
|
|
|
|
|
ptr, channels, &tmp_modifiers, strip->act, strip->strip_time, snapshot);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-12-23 18:43:01 +03:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* unlink this strip's modifiers from the parent's modifiers again */
|
|
|
|
|
nlaeval_fmodifiers_split_stacks(&strip->modifiers, modifiers);
|
2009-05-15 13:23:03 +00:00
|
|
|
}
|
|
|
|
|
|
2009-06-19 04:45:56 +00:00
|
|
|
/* evaluate transition strip */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
static void nlastrip_evaluate_transition(const int evaluation_mode,
|
|
|
|
|
PointerRNA *ptr,
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *modifiers,
|
|
|
|
|
NlaEvalStrip *nes,
|
2019-07-31 14:56:17 +02:00
|
|
|
NlaEvalSnapshot *snapshot,
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const AnimationEvalContext *anim_eval_context,
|
2019-07-31 14:56:17 +02:00
|
|
|
const bool flush_to_original)
|
2009-06-19 04:45:56 +00:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
ListBase tmp_modifiers = {nullptr, nullptr};
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalSnapshot snapshot1, snapshot2;
|
2009-06-19 04:45:56 +00:00
|
|
|
NlaEvalStrip tmp_nes;
|
|
|
|
|
NlaStrip *s1, *s2;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* join this strip's modifiers to the parent's modifiers (own modifiers first) */
|
|
|
|
|
nlaeval_fmodifiers_join_stacks(&tmp_modifiers, &nes->strip->modifiers, modifiers);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* get the two strips to operate on
|
2018-11-14 12:53:15 +11:00
|
|
|
* - we use the endpoints of the strips directly flanking our strip
|
|
|
|
|
* using these as the endpoints of the transition (destination and source)
|
|
|
|
|
* - these should have already been determined to be valid...
|
|
|
|
|
* - if this strip is being played in reverse, we need to swap these endpoints
|
|
|
|
|
* otherwise they will be interpolated wrong
|
2009-06-19 04:45:56 +00:00
|
|
|
*/
|
|
|
|
|
if (nes->strip->flag & NLASTRIP_FLAG_REVERSE) {
|
2012-05-12 16:11:34 +00:00
|
|
|
s1 = nes->strip->next;
|
|
|
|
|
s2 = nes->strip->prev;
|
2009-06-19 04:45:56 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2012-05-12 16:11:34 +00:00
|
|
|
s1 = nes->strip->prev;
|
|
|
|
|
s2 = nes->strip->next;
|
2009-06-19 04:45:56 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
switch (evaluation_mode) {
|
|
|
|
|
case STRIP_EVAL_BLEND: {
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* prepare template for 'evaluation strip'
|
|
|
|
|
* - based on the transition strip's evaluation strip data
|
|
|
|
|
* - strip_mode is NES_TIME_TRANSITION_* based on which endpoint
|
|
|
|
|
* - strip_time is the 'normalized' (i.e. in-strip) time for evaluation,
|
|
|
|
|
* which doubles up as an additional weighting factor for the strip influences
|
|
|
|
|
* which allows us to appear to be 'interpolating' between the two extremes
|
|
|
|
|
*/
|
|
|
|
|
tmp_nes = *nes;
|
|
|
|
|
|
|
|
|
|
/* evaluate these strips into a temp-buffer (tmp_channels) */
|
|
|
|
|
/* FIXME: modifier evaluation here needs some work... */
|
|
|
|
|
/* first strip */
|
|
|
|
|
tmp_nes.strip_mode = NES_TIME_TRANSITION_START;
|
|
|
|
|
tmp_nes.strip = s1;
|
|
|
|
|
tmp_nes.strip_time = s1->strip_time;
|
|
|
|
|
nlaeval_snapshot_init(&snapshot1, channels, snapshot);
|
|
|
|
|
nlasnapshot_blend_strip(ptr,
|
|
|
|
|
channels,
|
|
|
|
|
&tmp_modifiers,
|
|
|
|
|
&tmp_nes,
|
|
|
|
|
&snapshot1,
|
|
|
|
|
anim_eval_context,
|
|
|
|
|
flush_to_original);
|
|
|
|
|
|
|
|
|
|
/* second strip */
|
|
|
|
|
tmp_nes.strip_mode = NES_TIME_TRANSITION_END;
|
|
|
|
|
tmp_nes.strip = s2;
|
|
|
|
|
tmp_nes.strip_time = s2->strip_time;
|
|
|
|
|
nlaeval_snapshot_init(&snapshot2, channels, snapshot);
|
|
|
|
|
nlasnapshot_blend_strip(ptr,
|
|
|
|
|
channels,
|
|
|
|
|
&tmp_modifiers,
|
|
|
|
|
&tmp_nes,
|
|
|
|
|
&snapshot2,
|
|
|
|
|
anim_eval_context,
|
|
|
|
|
flush_to_original);
|
|
|
|
|
|
2023-07-31 10:15:30 +10:00
|
|
|
/**
|
|
|
|
|
* Replace \a snapshot2 nullptr channels with base or default values so all channels blend.
|
2023-07-17 10:46:26 +02:00
|
|
|
*/
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlasnapshot_ensure_channels(channels, &snapshot2);
|
|
|
|
|
/** Mark all \a snapshot2 channel's values to blend. */
|
|
|
|
|
nlasnapshot_enable_all_blend_domain(&snapshot2);
|
|
|
|
|
nlasnapshot_blend(
|
|
|
|
|
channels, &snapshot1, &snapshot2, NLASTRIP_MODE_REPLACE, nes->strip_time, snapshot);
|
|
|
|
|
|
|
|
|
|
nlaeval_snapshot_free_data(&snapshot1);
|
|
|
|
|
nlaeval_snapshot_free_data(&snapshot2);
|
|
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case STRIP_EVAL_BLEND_GET_INVERTED_LOWER_SNAPSHOT: {
|
|
|
|
|
/* No support for remapping values through a transition. Mark all channel values affected by
|
|
|
|
|
* transition as non-remappable. */
|
|
|
|
|
tmp_nes = *nes;
|
|
|
|
|
|
|
|
|
|
/* Process first strip. */
|
|
|
|
|
tmp_nes.strip = s1;
|
|
|
|
|
tmp_nes.strip_time = s1->strip_time;
|
|
|
|
|
nlaeval_snapshot_init(&snapshot1, channels, snapshot);
|
|
|
|
|
nlasnapshot_blend_strip_no_blend(
|
|
|
|
|
ptr, channels, &tmp_modifiers, &tmp_nes, &snapshot1, anim_eval_context);
|
|
|
|
|
|
|
|
|
|
/* Remove channel values affected by transition from the remap domain. */
|
|
|
|
|
LISTBASE_FOREACH (NlaEvalChannel *, nec, &channels->channels) {
|
|
|
|
|
NlaEvalChannelSnapshot *necs = nlaeval_snapshot_get(&snapshot1, nec->index);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (necs == nullptr) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
NlaEvalChannelSnapshot *output_necs = nlaeval_snapshot_ensure_channel(snapshot, nec);
|
|
|
|
|
for (int i = 0; i < necs->length; i++) {
|
|
|
|
|
if (BLI_BITMAP_TEST_BOOL(necs->blend_domain.ptr, i)) {
|
|
|
|
|
BLI_BITMAP_DISABLE(output_necs->remap_domain.ptr, i);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nlaeval_snapshot_free_data(&snapshot1);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* Process second strip. */
|
|
|
|
|
tmp_nes.strip = s2;
|
|
|
|
|
tmp_nes.strip_time = s2->strip_time;
|
|
|
|
|
nlaeval_snapshot_init(&snapshot2, channels, snapshot);
|
|
|
|
|
nlasnapshot_blend_strip_no_blend(
|
|
|
|
|
ptr, channels, &tmp_modifiers, &tmp_nes, &snapshot2, anim_eval_context);
|
2021-02-05 16:45:34 -05:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* Remove channel values affected by transition from the remap domain. */
|
|
|
|
|
LISTBASE_FOREACH (NlaEvalChannel *, nec, &channels->channels) {
|
|
|
|
|
NlaEvalChannelSnapshot *necs = nlaeval_snapshot_get(&snapshot2, nec->index);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (necs == nullptr) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
NlaEvalChannelSnapshot *output_necs = nlaeval_snapshot_ensure_channel(snapshot, nec);
|
|
|
|
|
for (int i = 0; i < necs->length; i++) {
|
|
|
|
|
if (BLI_BITMAP_TEST_BOOL(necs->blend_domain.ptr, i)) {
|
|
|
|
|
BLI_BITMAP_DISABLE(output_necs->remap_domain.ptr, i);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nlaeval_snapshot_free_data(&snapshot2);
|
|
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case STRIP_EVAL_NOBLEND: {
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_assert( !"This case shouldn't occur. Transitions assumed to not reference other "
|
|
|
|
|
"transitions. ");
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* unlink this strip's modifiers from the parent's modifiers again */
|
|
|
|
|
nlaeval_fmodifiers_split_stacks(&nes->strip->modifiers, modifiers);
|
2009-07-07 11:37:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* evaluate meta-strip */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
static void nlastrip_evaluate_meta(const int evaluation_mode,
|
|
|
|
|
PointerRNA *ptr,
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *modifiers,
|
|
|
|
|
NlaEvalStrip *nes,
|
2019-07-31 14:56:17 +02:00
|
|
|
NlaEvalSnapshot *snapshot,
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const AnimationEvalContext *anim_eval_context,
|
2019-07-31 14:56:17 +02:00
|
|
|
const bool flush_to_original)
|
2009-07-07 11:37:33 +00:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
ListBase tmp_modifiers = {nullptr, nullptr};
|
2012-05-12 16:11:34 +00:00
|
|
|
NlaStrip *strip = nes->strip;
|
2009-07-07 11:37:33 +00:00
|
|
|
NlaEvalStrip *tmp_nes;
|
|
|
|
|
float evaltime;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* meta-strip was calculated normally to have some time to be evaluated at
|
|
|
|
|
* and here we 'look inside' the meta strip, treating it as a decorated window to
|
2018-06-17 17:05:51 +02:00
|
|
|
* its child strips, which get evaluated as if they were some tracks on a strip
|
2009-07-07 11:37:33 +00:00
|
|
|
* (but with some extra modifiers to apply).
|
|
|
|
|
*
|
|
|
|
|
* NOTE: keep this in sync with animsys_evaluate_nla()
|
|
|
|
|
*/
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* join this strip's modifiers to the parent's modifiers (own modifiers first) */
|
2018-06-17 17:05:51 +02:00
|
|
|
nlaeval_fmodifiers_join_stacks(&tmp_modifiers, &strip->modifiers, modifiers);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* find the child-strip to evaluate */
|
2012-05-12 16:11:34 +00:00
|
|
|
evaltime = (nes->strip_time * (strip->end - strip->start)) + strip->start;
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
AnimationEvalContext child_context = BKE_animsys_eval_context_construct_at(anim_eval_context,
|
|
|
|
|
evaltime);
|
2023-07-17 10:46:26 +02:00
|
|
|
tmp_nes = nlastrips_ctime_get_strip(
|
|
|
|
|
nullptr, &strip->strips, -1, &child_context, flush_to_original);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* Assert currently supported modes. If new mode added, then assertion marks potentially missed
|
|
|
|
|
* area.
|
|
|
|
|
*
|
2023-09-08 16:58:00 +10:00
|
|
|
* NOTE: In the future if support is ever added to meta-strips to support nested tracks, then
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
* STRIP_EVAL_BLEND and STRIP_EVAL_BLEND_GET_INVERTED_LOWER_SNAPSHOT cases are no longer
|
|
|
|
|
* equivalent. The output of nlastrips_ctime_get_strip() may return a list of strips. The only
|
|
|
|
|
* case difference should be the evaluation order.
|
|
|
|
|
*/
|
|
|
|
|
BLI_assert(ELEM(evaluation_mode,
|
|
|
|
|
STRIP_EVAL_BLEND,
|
|
|
|
|
STRIP_EVAL_BLEND_GET_INVERTED_LOWER_SNAPSHOT,
|
|
|
|
|
STRIP_EVAL_NOBLEND));
|
|
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* directly evaluate child strip into accumulation buffer...
|
2023-02-12 14:37:16 +11:00
|
|
|
* - there's no need to use a temporary buffer (as it causes issues [#40082])
|
2014-05-08 21:00:59 +12:00
|
|
|
*/
|
2014-05-10 00:18:47 +12:00
|
|
|
if (tmp_nes) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlastrip_evaluate(evaluation_mode,
|
|
|
|
|
ptr,
|
|
|
|
|
channels,
|
|
|
|
|
&tmp_modifiers,
|
|
|
|
|
tmp_nes,
|
|
|
|
|
snapshot,
|
|
|
|
|
&child_context,
|
|
|
|
|
flush_to_original);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-05-10 00:18:47 +12:00
|
|
|
/* free temp eval-strip */
|
|
|
|
|
MEM_freeN(tmp_nes);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-07 12:17:06 +00:00
|
|
|
/* unlink this strip's modifiers from the parent's modifiers again */
|
|
|
|
|
nlaeval_fmodifiers_split_stacks(&strip->modifiers, modifiers);
|
2009-06-19 04:45:56 +00:00
|
|
|
}
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
void nlastrip_evaluate(const int evaluation_mode,
|
|
|
|
|
PointerRNA *ptr,
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *modifiers,
|
|
|
|
|
NlaEvalStrip *nes,
|
2019-07-31 14:56:17 +02:00
|
|
|
NlaEvalSnapshot *snapshot,
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const AnimationEvalContext *anim_eval_context,
|
2019-07-31 14:56:17 +02:00
|
|
|
const bool flush_to_original)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
2012-05-12 16:11:34 +00:00
|
|
|
NlaStrip *strip = nes->strip;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-27 12:07:07 +10:00
|
|
|
/* To prevent potential infinite recursion problems
|
|
|
|
|
* (i.e. transition strip, beside meta strip containing a transition
|
|
|
|
|
* several levels deep inside it),
|
|
|
|
|
* we tag the current strip as being evaluated, and clear this when we leave.
|
2009-07-12 04:29:36 +00:00
|
|
|
*/
|
2019-04-27 12:07:07 +10:00
|
|
|
/* TODO: be careful with this flag, since some edit tools may be running and have
|
2019-06-12 09:04:10 +10:00
|
|
|
* set this while animation playback was running. */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (strip->flag & NLASTRIP_FLAG_EDIT_TOUCHED) {
|
2009-07-12 04:29:36 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2009-07-12 04:29:36 +00:00
|
|
|
strip->flag |= NLASTRIP_FLAG_EDIT_TOUCHED;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-05-15 13:23:03 +00:00
|
|
|
/* actions to take depend on the type of strip */
|
2009-07-12 04:29:36 +00:00
|
|
|
switch (strip->type) {
|
2009-05-15 13:23:03 +00:00
|
|
|
case NLASTRIP_TYPE_CLIP: /* action-clip */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlastrip_evaluate_actionclip(evaluation_mode, ptr, channels, modifiers, nes, snapshot);
|
2009-05-15 13:23:03 +00:00
|
|
|
break;
|
|
|
|
|
case NLASTRIP_TYPE_TRANSITION: /* transition */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlastrip_evaluate_transition(evaluation_mode,
|
|
|
|
|
ptr,
|
|
|
|
|
channels,
|
|
|
|
|
modifiers,
|
|
|
|
|
nes,
|
|
|
|
|
snapshot,
|
|
|
|
|
anim_eval_context,
|
|
|
|
|
flush_to_original);
|
2009-05-15 13:23:03 +00:00
|
|
|
break;
|
2009-07-07 11:37:33 +00:00
|
|
|
case NLASTRIP_TYPE_META: /* meta */
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlastrip_evaluate_meta(evaluation_mode,
|
|
|
|
|
ptr,
|
|
|
|
|
channels,
|
|
|
|
|
modifiers,
|
|
|
|
|
nes,
|
|
|
|
|
snapshot,
|
|
|
|
|
anim_eval_context,
|
|
|
|
|
flush_to_original);
|
2009-07-07 11:37:33 +00:00
|
|
|
break;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-08-07 12:27:20 +00:00
|
|
|
default: /* do nothing */
|
|
|
|
|
break;
|
2009-05-15 13:23:03 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-12 04:29:36 +00:00
|
|
|
/* clear temp recursion safe-check */
|
|
|
|
|
strip->flag &= ~NLASTRIP_FLAG_EDIT_TOUCHED;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
void nlasnapshot_blend_strip(PointerRNA *ptr,
|
|
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *modifiers,
|
|
|
|
|
NlaEvalStrip *nes,
|
|
|
|
|
NlaEvalSnapshot *snapshot,
|
2023-06-03 08:36:28 +10:00
|
|
|
const AnimationEvalContext *anim_eval_context,
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
const bool flush_to_original)
|
|
|
|
|
{
|
|
|
|
|
nlastrip_evaluate(STRIP_EVAL_BLEND,
|
|
|
|
|
ptr,
|
|
|
|
|
channels,
|
|
|
|
|
modifiers,
|
|
|
|
|
nes,
|
|
|
|
|
snapshot,
|
|
|
|
|
anim_eval_context,
|
|
|
|
|
flush_to_original);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void nlasnapshot_blend_strip_get_inverted_lower_snapshot(
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *modifiers,
|
|
|
|
|
NlaEvalStrip *nes,
|
|
|
|
|
NlaEvalSnapshot *snapshot,
|
2023-06-03 08:36:28 +10:00
|
|
|
const AnimationEvalContext *anim_eval_context)
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
{
|
|
|
|
|
nlastrip_evaluate(STRIP_EVAL_BLEND_GET_INVERTED_LOWER_SNAPSHOT,
|
|
|
|
|
ptr,
|
|
|
|
|
channels,
|
|
|
|
|
modifiers,
|
|
|
|
|
nes,
|
|
|
|
|
snapshot,
|
|
|
|
|
anim_eval_context,
|
|
|
|
|
false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void nlasnapshot_blend_strip_no_blend(PointerRNA *ptr,
|
|
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *modifiers,
|
|
|
|
|
NlaEvalStrip *nes,
|
|
|
|
|
NlaEvalSnapshot *snapshot,
|
2023-06-03 08:36:28 +10:00
|
|
|
const AnimationEvalContext *anim_eval_context)
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
{
|
|
|
|
|
nlastrip_evaluate(
|
|
|
|
|
STRIP_EVAL_NOBLEND, ptr, channels, modifiers, nes, snapshot, anim_eval_context, false);
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-31 14:56:17 +02:00
|
|
|
void nladata_flush_channels(PointerRNA *ptr,
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalData *channels,
|
2019-07-31 14:56:17 +02:00
|
|
|
NlaEvalSnapshot *snapshot,
|
|
|
|
|
const bool flush_to_original)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
2009-05-16 01:00:41 +00:00
|
|
|
/* sanity checks */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (channels == nullptr) {
|
2009-05-16 01:00:41 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-05-16 01:00:41 +00:00
|
|
|
/* for each channel with accumulated values, write its value on the property it affects */
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (NlaEvalChannel *, nec, &channels->channels) {
|
2021-01-14 19:27:46 -05:00
|
|
|
/**
|
|
|
|
|
* The bitmask is set for all channels touched by NLA due to the domain() function.
|
|
|
|
|
* Channels touched by current set of evaluated strips will have a snapshot channel directly
|
|
|
|
|
* from the evaluation snapshot.
|
|
|
|
|
*
|
|
|
|
|
* This function falls back to the default value if the snapshot channel doesn't exist.
|
|
|
|
|
* Thus channels, touched by NLA but not by the current set of evaluated strips, will be
|
|
|
|
|
* reset to default. If channel not touched by NLA then it's value is unchanged.
|
|
|
|
|
*/
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalChannelSnapshot *nec_snapshot = nlaeval_snapshot_find_channel(snapshot, nec);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
PathResolvedRNA rna = {nec->key.ptr, nec->key.prop, -1};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
for (int i = 0; i < nec_snapshot->length; i++) {
|
2021-01-14 19:27:46 -05:00
|
|
|
if (BLI_BITMAP_TEST(nec->domain.ptr, i)) {
|
2018-12-15 16:09:27 +03:00
|
|
|
float value = nec_snapshot->values[i];
|
|
|
|
|
if (nec->is_array) {
|
|
|
|
|
rna.prop_index = i;
|
|
|
|
|
}
|
2021-03-01 18:42:48 +01:00
|
|
|
BKE_animsys_write_to_rna_path(&rna, value);
|
2019-07-31 14:56:17 +02:00
|
|
|
if (flush_to_original) {
|
2018-12-15 16:09:27 +03:00
|
|
|
animsys_write_orig_anim_rna(ptr, nec->rna_path, rna.prop_index, value);
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-05-16 01:00:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ---------------------- */
|
|
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
static void nla_eval_domain_action(PointerRNA *ptr,
|
|
|
|
|
NlaEvalData *channels,
|
|
|
|
|
bAction *act,
|
|
|
|
|
GSet *touched_actions)
|
|
|
|
|
{
|
|
|
|
|
if (!BLI_gset_add(touched_actions, act)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (FCurve *, fcu, &act->curves) {
|
2018-12-15 16:09:27 +03:00
|
|
|
/* check if this curve should be skipped */
|
2021-01-14 18:46:28 -05:00
|
|
|
if (!is_fcurve_evaluatable(fcu)) {
|
2019-05-15 22:26:58 +03:00
|
|
|
continue;
|
|
|
|
|
}
|
2018-12-15 16:09:27 +03:00
|
|
|
|
|
|
|
|
NlaEvalChannel *nec = nlaevalchan_verify(ptr, channels, fcu->rna_path);
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (nec != nullptr) {
|
2018-12-23 18:43:01 +03:00
|
|
|
/* For quaternion properties, enable all sub-channels. */
|
|
|
|
|
if (nec->mix_mode == NEC_MIX_QUATERNION) {
|
2021-01-14 19:27:46 -05:00
|
|
|
BLI_bitmap_set_all(nec->domain.ptr, true, 4);
|
2018-12-23 18:43:01 +03:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
int idx = nlaevalchan_validate_index(nec, fcu->array_index);
|
|
|
|
|
|
|
|
|
|
if (idx >= 0) {
|
2021-01-14 19:27:46 -05:00
|
|
|
BLI_BITMAP_ENABLE(nec->domain.ptr, idx);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void nla_eval_domain_strips(PointerRNA *ptr,
|
|
|
|
|
NlaEvalData *channels,
|
|
|
|
|
ListBase *strips,
|
|
|
|
|
GSet *touched_actions)
|
|
|
|
|
{
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (NlaStrip *, strip, strips) {
|
2021-05-14 17:35:22 +10:00
|
|
|
/* Check strip's action. */
|
2018-12-15 16:09:27 +03:00
|
|
|
if (strip->act) {
|
|
|
|
|
nla_eval_domain_action(ptr, channels, strip->act, touched_actions);
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-14 17:35:22 +10:00
|
|
|
/* Check sub-strips (if meta-strips). */
|
2018-12-15 16:09:27 +03:00
|
|
|
nla_eval_domain_strips(ptr, channels, &strip->strips, touched_actions);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Ensure that all channels touched by any of the actions in enabled tracks exist.
|
|
|
|
|
* This is necessary to ensure that evaluation result depends only on current frame.
|
|
|
|
|
*/
|
|
|
|
|
static void animsys_evaluate_nla_domain(PointerRNA *ptr, NlaEvalData *channels, AnimData *adt)
|
|
|
|
|
{
|
|
|
|
|
GSet *touched_actions = BLI_gset_ptr_new(__func__);
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* Include domain of Action Track. */
|
|
|
|
|
if ((adt->flag & ADT_NLA_EDIT_ON) == 0) {
|
|
|
|
|
if (adt->action) {
|
|
|
|
|
nla_eval_domain_action(ptr, channels, adt->action, touched_actions);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if (adt->tmpact && (adt->flag & ADT_NLA_EVAL_UPPER_TRACKS)) {
|
|
|
|
|
nla_eval_domain_action(ptr, channels, adt->tmpact, touched_actions);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* NLA Data - Animation Data for Strips */
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (NlaTrack *, nlt, &adt->nla_tracks) {
|
2018-12-15 16:09:27 +03:00
|
|
|
/* solo and muting are mutually exclusive... */
|
|
|
|
|
if (adt->flag & ADT_NLA_SOLO_TRACK) {
|
|
|
|
|
/* skip if there is a solo track, but this isn't it */
|
2019-04-22 09:39:35 +10:00
|
|
|
if ((nlt->flag & NLATRACK_SOLO) == 0) {
|
2018-12-15 16:09:27 +03:00
|
|
|
continue;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-12-15 16:09:27 +03:00
|
|
|
/* else - mute doesn't matter */
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* no solo tracks - skip track if muted */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (nlt->flag & NLATRACK_MUTED) {
|
2018-12-15 16:09:27 +03:00
|
|
|
continue;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nla_eval_domain_strips(ptr, channels, &nlt->strips, touched_actions);
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_gset_free(touched_actions, nullptr);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ---------------------- */
|
|
|
|
|
|
2021-04-09 18:47:10 +10:00
|
|
|
/**
|
|
|
|
|
* Tweaked strip is evaluated differently from other strips. Adjacent strips are ignored
|
|
|
|
|
* and includes a workaround for when user is not editing in place.
|
|
|
|
|
*/
|
2021-01-14 18:25:01 -05:00
|
|
|
static void animsys_create_tweak_strip(const AnimData *adt,
|
|
|
|
|
const bool keyframing_to_strip,
|
|
|
|
|
NlaStrip *r_tweak_strip)
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
/* Copy active strip so we can modify how it evaluates without affecting user data. */
|
|
|
|
|
memcpy(r_tweak_strip, adt->actstrip, sizeof(NlaStrip));
|
2023-07-17 10:46:26 +02:00
|
|
|
r_tweak_strip->next = r_tweak_strip->prev = nullptr;
|
2021-01-14 18:25:01 -05:00
|
|
|
|
|
|
|
|
/* If tweaked strip is syncing action length, then evaluate using action length. */
|
|
|
|
|
if (r_tweak_strip->flag & NLASTRIP_FLAG_SYNC_LENGTH) {
|
|
|
|
|
BKE_nlastrip_recalculate_bounds_sync_action(r_tweak_strip);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Strips with a user-defined time curve don't get properly remapped for editing
|
|
|
|
|
* at the moment, so mapping them just for display may be confusing. */
|
|
|
|
|
const bool is_inplace_tweak = !(adt->flag & ADT_NLA_EDIT_NOMAP) &&
|
|
|
|
|
!(adt->actstrip->flag & NLASTRIP_FLAG_USR_TIME);
|
|
|
|
|
|
|
|
|
|
if (!is_inplace_tweak) {
|
|
|
|
|
/* Use Hold due to no proper remapping yet (the note above). */
|
|
|
|
|
r_tweak_strip->extendmode = NLASTRIP_EXTEND_HOLD;
|
|
|
|
|
|
|
|
|
|
/* Disable range. */
|
|
|
|
|
r_tweak_strip->flag |= NLASTRIP_FLAG_NO_TIME_MAP;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** Controls whether able to keyframe outside range of tweaked strip. */
|
|
|
|
|
if (keyframing_to_strip) {
|
|
|
|
|
r_tweak_strip->extendmode = (is_inplace_tweak &&
|
|
|
|
|
!(r_tweak_strip->flag & NLASTRIP_FLAG_SYNC_LENGTH)) ?
|
|
|
|
|
NLASTRIP_EXTEND_NOTHING :
|
|
|
|
|
NLASTRIP_EXTEND_HOLD;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** Action track and strip are associated with the non-pushed action. */
|
|
|
|
|
static void animsys_create_action_track_strip(const AnimData *adt,
|
|
|
|
|
const bool keyframing_to_strip,
|
|
|
|
|
NlaStrip *r_action_strip)
|
|
|
|
|
{
|
|
|
|
|
memset(r_action_strip, 0, sizeof(NlaStrip));
|
|
|
|
|
|
|
|
|
|
bAction *action = adt->action;
|
|
|
|
|
|
2021-08-05 16:48:29 +10:00
|
|
|
if (adt->flag & ADT_NLA_EDIT_ON) {
|
2021-01-14 18:25:01 -05:00
|
|
|
action = adt->tmpact;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Set settings of dummy NLA strip from AnimData settings. */
|
|
|
|
|
r_action_strip->act = action;
|
|
|
|
|
|
|
|
|
|
/* Action range is calculated taking F-Modifiers into account
|
|
|
|
|
* (which making new strips doesn't do due to the troublesome nature of that). */
|
2023-07-09 18:17:58 +10:00
|
|
|
BKE_action_frame_range_calc(
|
|
|
|
|
r_action_strip->act, true, &r_action_strip->actstart, &r_action_strip->actend);
|
2023-09-26 18:18:56 +02:00
|
|
|
BKE_nla_clip_length_ensure_nonzero(&r_action_strip->actstart, &r_action_strip->actend);
|
2021-01-14 18:25:01 -05:00
|
|
|
r_action_strip->start = r_action_strip->actstart;
|
2023-09-26 18:18:56 +02:00
|
|
|
r_action_strip->end = r_action_strip->actend;
|
2021-01-14 18:25:01 -05:00
|
|
|
|
|
|
|
|
r_action_strip->blendmode = adt->act_blendmode;
|
|
|
|
|
r_action_strip->extendmode = adt->act_extendmode;
|
|
|
|
|
r_action_strip->influence = adt->act_influence;
|
|
|
|
|
|
2023-09-11 18:40:31 +02:00
|
|
|
/* Must set NLASTRIP_FLAG_USR_INFLUENCE, or else the default setting overrides, and influence
|
|
|
|
|
* doesn't work.
|
2021-01-14 18:25:01 -05:00
|
|
|
*/
|
2024-01-11 18:44:44 +01:00
|
|
|
r_action_strip->flag |= NLASTRIP_FLAG_USR_INFLUENCE | NLASTRIP_FLAG_NO_TIME_MAP;
|
2021-01-14 18:25:01 -05:00
|
|
|
|
|
|
|
|
const bool tweaking = (adt->flag & ADT_NLA_EDIT_ON) != 0;
|
|
|
|
|
const bool soloing = (adt->flag & ADT_NLA_SOLO_TRACK) != 0;
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
const bool eval_upper = !tweaking || (adt->flag & ADT_NLA_EVAL_UPPER_TRACKS) != 0;
|
|
|
|
|
const bool actionstrip_evaluated = r_action_strip->act && !soloing && eval_upper;
|
2021-01-14 18:25:01 -05:00
|
|
|
if (!actionstrip_evaluated) {
|
|
|
|
|
r_action_strip->flag |= NLASTRIP_FLAG_MUTED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** If we're keyframing, then we must allow keyframing outside fcurve bounds. */
|
|
|
|
|
if (keyframing_to_strip) {
|
|
|
|
|
r_action_strip->extendmode = NLASTRIP_EXTEND_HOLD;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool is_nlatrack_evaluatable(const AnimData *adt, const NlaTrack *nlt)
|
|
|
|
|
{
|
|
|
|
|
/* Skip disabled tracks unless it contains the tweaked strip. */
|
2021-07-30 11:58:02 +02:00
|
|
|
const bool contains_tweak_strip = (adt->flag & ADT_NLA_EDIT_ON) && adt->act_track &&
|
2021-01-14 18:25:01 -05:00
|
|
|
(nlt->index == adt->act_track->index);
|
|
|
|
|
if ((nlt->flag & NLATRACK_DISABLED) && !contains_tweak_strip) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Solo and muting are mutually exclusive. */
|
|
|
|
|
if (adt->flag & ADT_NLA_SOLO_TRACK) {
|
|
|
|
|
/* Skip if there is a solo track, but this isn't it. */
|
|
|
|
|
if ((nlt->flag & NLATRACK_SOLO) == 0) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* Skip track if muted. */
|
|
|
|
|
if (nlt->flag & NLATRACK_MUTED) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-09 18:47:10 +10:00
|
|
|
/**
|
|
|
|
|
* Check for special case of non-pushed action being evaluated with no NLA influence (off and no
|
|
|
|
|
* strips evaluated) nor NLA interference (ensure NLA not soloing).
|
|
|
|
|
*/
|
2021-01-14 18:25:01 -05:00
|
|
|
static bool is_action_track_evaluated_without_nla(const AnimData *adt,
|
|
|
|
|
const bool any_strip_evaluated)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
if (adt->action == nullptr) {
|
2021-01-14 18:25:01 -05:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (any_strip_evaluated) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** NLA settings interference. */
|
2021-02-05 17:47:56 -05:00
|
|
|
if ((adt->flag & (ADT_NLA_SOLO_TRACK | ADT_NLA_EDIT_ON)) != 0) {
|
2021-01-14 18:25:01 -05:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** Allow action track to evaluate as if there isn't any NLA data. */
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-20 15:24:52 +11:00
|
|
|
/**
|
2023-07-31 11:50:54 +10:00
|
|
|
* XXX(Wayde Moss): #BKE_nlatrack_find_tweaked() exists within `nla.cc`, but it doesn't appear to
|
2023-07-17 10:46:26 +02:00
|
|
|
* work as expected. From #animsys_evaluate_nla_for_flush(), it returns nullptr in tweak mode. I'm
|
|
|
|
|
* not sure why. Preferably, it would be as simple as checking for `(adt->act_Track == nlt)` but
|
|
|
|
|
* that doesn't work either, neither does comparing indices.
|
2021-01-14 18:25:01 -05:00
|
|
|
*
|
2023-02-27 21:44:59 +11:00
|
|
|
* This function is a temporary work around. The first disabled track is always the tweaked track.
|
2021-01-14 18:25:01 -05:00
|
|
|
*/
|
|
|
|
|
static NlaTrack *nlatrack_find_tweaked(const AnimData *adt)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
if (adt == nullptr) {
|
|
|
|
|
return nullptr;
|
2021-01-14 18:25:01 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Since the track itself gets disabled, we want the first disabled. */
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (NlaTrack *, nlt, &adt->nla_tracks) {
|
2021-01-14 18:25:01 -05:00
|
|
|
if (nlt->flag & NLATRACK_DISABLED) {
|
|
|
|
|
return nlt;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2021-01-14 18:25:01 -05:00
|
|
|
}
|
|
|
|
|
|
2014-05-29 21:16:04 +10:00
|
|
|
/**
|
|
|
|
|
* NLA Evaluation function - values are calculated and stored in temporary "NlaEvalChannels"
|
2019-04-27 12:07:07 +10:00
|
|
|
* \param[out] echannels: Evaluation channels with calculated values
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*/
|
2021-01-14 18:25:01 -05:00
|
|
|
static bool animsys_evaluate_nla_for_flush(NlaEvalData *echannels,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
const AnimData *adt,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
const bool flush_to_original)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
|
|
|
|
NlaTrack *nlt;
|
2012-05-12 16:11:34 +00:00
|
|
|
short track_index = 0;
|
2014-01-28 03:52:21 +11:00
|
|
|
bool has_strips = false;
|
2023-07-17 10:46:26 +02:00
|
|
|
ListBase estrips = {nullptr, nullptr};
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
NlaEvalStrip *nes;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
NlaStrip tweak_strip;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
NlaTrack *tweaked_track = nlatrack_find_tweaked(adt);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
/* Get the stack of strips to evaluate at current time (influence calculated here). */
|
2023-07-17 10:46:26 +02:00
|
|
|
for (nlt = static_cast<NlaTrack *>(adt->nla_tracks.first); nlt; nlt = nlt->next, track_index++) {
|
2021-01-14 18:25:01 -05:00
|
|
|
|
|
|
|
|
if (!is_nlatrack_evaluatable(adt, nlt)) {
|
|
|
|
|
continue;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
if (nlt->strips.first) {
|
|
|
|
|
has_strips = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** Append strip to evaluate for this track. */
|
|
|
|
|
if (nlt == tweaked_track) {
|
|
|
|
|
/** Tweaked strip is evaluated differently. */
|
|
|
|
|
animsys_create_tweak_strip(adt, false, &tweak_strip);
|
|
|
|
|
nes = nlastrips_ctime_get_strip_single(
|
|
|
|
|
&estrips, &tweak_strip, anim_eval_context, flush_to_original);
|
2015-02-27 19:36:13 +13:00
|
|
|
}
|
|
|
|
|
else {
|
2021-01-14 18:25:01 -05:00
|
|
|
nes = nlastrips_ctime_get_strip(
|
|
|
|
|
&estrips, &nlt->strips, track_index, anim_eval_context, flush_to_original);
|
|
|
|
|
}
|
|
|
|
|
if (nes) {
|
|
|
|
|
nes->track = nlt;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (is_action_track_evaluated_without_nla(adt, has_strips)) {
|
|
|
|
|
BLI_freelistN(&estrips);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-03 19:14:53 +10:00
|
|
|
NlaStrip action_strip = {nullptr};
|
2021-01-14 18:25:01 -05:00
|
|
|
animsys_create_action_track_strip(adt, false, &action_strip);
|
|
|
|
|
nlastrips_ctime_get_strip_single(&estrips, &action_strip, anim_eval_context, flush_to_original);
|
|
|
|
|
|
|
|
|
|
/* Per strip, evaluate and accumulate on top of existing channels. */
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (NlaEvalStrip *, nes, &estrips) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlasnapshot_blend_strip(ptr,
|
|
|
|
|
echannels,
|
2023-07-17 10:46:26 +02:00
|
|
|
nullptr,
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nes,
|
|
|
|
|
&echannels->eval_snapshot,
|
|
|
|
|
anim_eval_context,
|
|
|
|
|
flush_to_original);
|
2021-01-14 18:25:01 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Free temporary evaluation data that's not used elsewhere. */
|
|
|
|
|
BLI_freelistN(&estrips);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** Lower blended values are calculated and accumulated into r_context->lower_eval_data. */
|
|
|
|
|
static void animsys_evaluate_nla_for_keyframing(PointerRNA *ptr,
|
|
|
|
|
const AnimData *adt,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
NlaKeyframingContext *r_context)
|
|
|
|
|
{
|
|
|
|
|
if (!r_context) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Early out. If NLA track is soloing and tweaked action isn't it, then don't allow keyframe
|
|
|
|
|
* insertion. */
|
|
|
|
|
if (adt->flag & ADT_NLA_SOLO_TRACK) {
|
|
|
|
|
if (!(adt->act_track && (adt->act_track->flag & NLATRACK_SOLO))) {
|
2023-07-17 10:46:26 +02:00
|
|
|
r_context->eval_strip = nullptr;
|
2021-01-14 18:25:01 -05:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
NlaTrack *nlt;
|
|
|
|
|
short track_index = 0;
|
|
|
|
|
bool has_strips = false;
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
ListBase *upper_estrips = &r_context->upper_estrips;
|
2023-07-17 10:46:26 +02:00
|
|
|
ListBase lower_estrips = {nullptr, nullptr};
|
2021-01-14 18:25:01 -05:00
|
|
|
NlaEvalStrip *nes;
|
|
|
|
|
|
|
|
|
|
NlaTrack *tweaked_track = nlatrack_find_tweaked(adt);
|
|
|
|
|
|
|
|
|
|
/* Get the lower stack of strips to evaluate at current time (influence calculated here). */
|
2023-07-17 10:46:26 +02:00
|
|
|
for (nlt = static_cast<NlaTrack *>(adt->nla_tracks.first); nlt; nlt = nlt->next, track_index++) {
|
2021-01-14 18:25:01 -05:00
|
|
|
|
|
|
|
|
if (!is_nlatrack_evaluatable(adt, nlt)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Tweaked strip effect should not be stored in any snapshot. */
|
|
|
|
|
if (nlt == tweaked_track) {
|
|
|
|
|
break;
|
2015-02-27 19:36:13 +13:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (nlt->strips.first) {
|
2014-05-08 21:00:59 +12:00
|
|
|
has_strips = true;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
/* Get strip to evaluate for this channel. */
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
nes = nlastrips_ctime_get_strip(
|
2021-01-14 18:25:01 -05:00
|
|
|
&lower_estrips, &nlt->strips, track_index, anim_eval_context, false);
|
2019-04-22 09:39:35 +10:00
|
|
|
if (nes) {
|
2012-05-12 16:11:34 +00:00
|
|
|
nes->track = nlt;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2009-06-05 11:51:27 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* Get the upper stack of strips to evaluate at current time (influence calculated here).
|
|
|
|
|
* Var nlt exists only if tweak strip exists. */
|
|
|
|
|
if (nlt) {
|
|
|
|
|
|
|
|
|
|
/* Skip tweaked strip. */
|
|
|
|
|
nlt = nlt->next;
|
|
|
|
|
track_index++;
|
|
|
|
|
|
|
|
|
|
for (; nlt; nlt = nlt->next, track_index++) {
|
|
|
|
|
|
|
|
|
|
if (!is_nlatrack_evaluatable(adt, nlt)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (nlt->strips.first) {
|
|
|
|
|
has_strips = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Get strip to evaluate for this channel. */
|
|
|
|
|
nes = nlastrips_ctime_get_strip(
|
|
|
|
|
upper_estrips, &nlt->strips, track_index, anim_eval_context, false);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-27 15:10:58 +10:00
|
|
|
/* NOTE: Although we early out, we can still keyframe to the non-pushed action since the
|
2023-07-17 10:46:26 +02:00
|
|
|
* keyframe remap function detects (r_context->strip.act == nullptr) and will keyframe without
|
2023-05-27 15:10:58 +10:00
|
|
|
* remapping. */
|
2021-01-14 18:25:01 -05:00
|
|
|
if (is_action_track_evaluated_without_nla(adt, has_strips)) {
|
|
|
|
|
BLI_freelistN(&lower_estrips);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
/* Write r_context->eval_strip. */
|
|
|
|
|
if (adt->flag & ADT_NLA_EDIT_ON) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* Append action_track_strip to upper estrips. */
|
|
|
|
|
NlaStrip *action_strip = &r_context->action_track_strip;
|
|
|
|
|
animsys_create_action_track_strip(adt, false, action_strip);
|
|
|
|
|
nlastrips_ctime_get_strip_single(upper_estrips, action_strip, anim_eval_context, false);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
NlaStrip *tweak_strip = &r_context->strip;
|
|
|
|
|
animsys_create_tweak_strip(adt, true, tweak_strip);
|
|
|
|
|
r_context->eval_strip = nlastrips_ctime_get_strip_single(
|
2023-07-17 10:46:26 +02:00
|
|
|
nullptr, tweak_strip, anim_eval_context, false);
|
2021-01-14 18:25:01 -05:00
|
|
|
}
|
|
|
|
|
else {
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
NlaStrip *action_strip = &r_context->strip;
|
|
|
|
|
animsys_create_action_track_strip(adt, true, action_strip);
|
|
|
|
|
r_context->eval_strip = nlastrips_ctime_get_strip_single(
|
2023-07-17 10:46:26 +02:00
|
|
|
nullptr, action_strip, anim_eval_context, false);
|
2021-01-14 18:25:01 -05:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
/* If nullptr, then keyframing will fail. No need to do any more processing. */
|
2021-01-14 18:25:01 -05:00
|
|
|
if (!r_context->eval_strip) {
|
|
|
|
|
BLI_freelistN(&lower_estrips);
|
|
|
|
|
return;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
/* If tweak strip is full REPLACE, then lower strips not needed. */
|
|
|
|
|
if (r_context->strip.blendmode == NLASTRIP_MODE_REPLACE &&
|
|
|
|
|
IS_EQF(r_context->strip.influence, 1.0f))
|
|
|
|
|
{
|
|
|
|
|
BLI_freelistN(&lower_estrips);
|
|
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
/* For each strip, evaluate then accumulate on top of existing channels. */
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (NlaEvalStrip *, nes, &lower_estrips) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlasnapshot_blend_strip(ptr,
|
|
|
|
|
&r_context->lower_eval_data,
|
2023-07-17 10:46:26 +02:00
|
|
|
nullptr,
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nes,
|
|
|
|
|
&r_context->lower_eval_data.eval_snapshot,
|
|
|
|
|
anim_eval_context,
|
|
|
|
|
false);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-14 18:25:01 -05:00
|
|
|
/* Free temporary evaluation data that's not used elsewhere. */
|
|
|
|
|
BLI_freelistN(&lower_estrips);
|
2011-03-29 09:37:53 +00:00
|
|
|
}
|
|
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* NLA Evaluation function (mostly for use through do_animdata)
|
2018-11-14 12:53:15 +11:00
|
|
|
* - All channels that will be affected are not cleared anymore. Instead, we just evaluate into
|
|
|
|
|
* some temp channels, where values can be accumulated in one go.
|
2011-03-29 09:37:53 +00:00
|
|
|
*/
|
2019-07-31 14:56:17 +02:00
|
|
|
static void animsys_calculate_nla(PointerRNA *ptr,
|
2018-05-31 12:52:13 +02:00
|
|
|
AnimData *adt,
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const AnimationEvalContext *anim_eval_context,
|
2019-07-31 14:56:17 +02:00
|
|
|
const bool flush_to_original)
|
2011-03-29 09:37:53 +00:00
|
|
|
{
|
2018-12-15 16:09:27 +03:00
|
|
|
NlaEvalData echannels;
|
2012-07-06 23:56:59 +00:00
|
|
|
|
2018-12-15 16:09:27 +03:00
|
|
|
nlaeval_init(&echannels);
|
2012-07-06 23:56:59 +00:00
|
|
|
|
2011-03-29 09:37:53 +00:00
|
|
|
/* evaluate the NLA stack, obtaining a set of values to flush */
|
2021-01-14 18:25:01 -05:00
|
|
|
if (animsys_evaluate_nla_for_flush(&echannels, ptr, adt, anim_eval_context, flush_to_original)) {
|
2018-12-15 16:09:27 +03:00
|
|
|
/* reset any channels touched by currently inactive actions to default value */
|
|
|
|
|
animsys_evaluate_nla_domain(ptr, &echannels, adt);
|
|
|
|
|
|
|
|
|
|
/* flush effects of accumulating channels in NLA to the actual data they affect */
|
2019-07-31 14:56:17 +02:00
|
|
|
nladata_flush_channels(ptr, &echannels, &echannels.eval_snapshot, flush_to_original);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* special case - evaluate as if there isn't any NLA data */
|
|
|
|
|
/* TODO: this is really just a stop-gap measure... */
|
2019-04-22 09:39:35 +10:00
|
|
|
if (G.debug & G_DEBUG) {
|
2019-02-01 12:44:19 +11:00
|
|
|
CLOG_WARN(&LOG, "NLA Eval: Stopgap for active action on NLA Stack - no strips case");
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
animsys_evaluate_action(ptr, adt->action, anim_eval_context, flush_to_original);
|
2018-12-15 16:09:27 +03:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2011-03-29 09:37:53 +00:00
|
|
|
/* free temp data */
|
2018-12-15 16:09:27 +03:00
|
|
|
nlaeval_free(&echannels);
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
2018-11-12 19:41:53 +03:00
|
|
|
/* ---------------------- */
|
|
|
|
|
|
2021-02-16 23:58:29 -05:00
|
|
|
void nlasnapshot_enable_all_blend_domain(NlaEvalSnapshot *snapshot)
|
|
|
|
|
{
|
|
|
|
|
for (int i = 0; i < snapshot->size; i++) {
|
|
|
|
|
NlaEvalChannelSnapshot *necs = nlaeval_snapshot_get(snapshot, i);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (necs == nullptr) {
|
2021-02-16 23:58:29 -05:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-17 01:06:41 -05:00
|
|
|
BLI_bitmap_set_all(necs->blend_domain.ptr, true, necs->length);
|
2021-02-16 23:58:29 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-05 16:45:34 -05:00
|
|
|
void nlasnapshot_ensure_channels(NlaEvalData *eval_data, NlaEvalSnapshot *snapshot)
|
|
|
|
|
{
|
|
|
|
|
LISTBASE_FOREACH (NlaEvalChannel *, nec, &eval_data->channels) {
|
|
|
|
|
nlaeval_snapshot_ensure_channel(snapshot, nec);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-03 16:23:18 -05:00
|
|
|
void nlasnapshot_blend(NlaEvalData *eval_data,
|
|
|
|
|
NlaEvalSnapshot *lower_snapshot,
|
|
|
|
|
NlaEvalSnapshot *upper_snapshot,
|
|
|
|
|
const short upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalSnapshot *r_blended_snapshot)
|
|
|
|
|
{
|
|
|
|
|
nlaeval_snapshot_ensure_size(r_blended_snapshot, eval_data->num_channels);
|
|
|
|
|
|
|
|
|
|
LISTBASE_FOREACH (NlaEvalChannel *, nec, &eval_data->channels) {
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs = nlaeval_snapshot_get(upper_snapshot, nec->index);
|
|
|
|
|
NlaEvalChannelSnapshot *lower_necs = nlaeval_snapshot_get(lower_snapshot, nec->index);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (upper_necs == nullptr && lower_necs == nullptr) {
|
2021-02-03 16:23:18 -05:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-03 17:35:21 -05:00
|
|
|
/** Blend with lower_snapshot's base or default. */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (lower_necs == nullptr) {
|
2021-02-03 17:35:21 -05:00
|
|
|
lower_necs = nlaeval_snapshot_find_channel(lower_snapshot->base, nec);
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-03 16:23:18 -05:00
|
|
|
NlaEvalChannelSnapshot *result_necs = nlaeval_snapshot_ensure_channel(r_blended_snapshot, nec);
|
2021-05-11 16:04:18 -04:00
|
|
|
nlaevalchan_blendOrcombine(
|
|
|
|
|
lower_necs, upper_necs, upper_blendmode, upper_influence, result_necs);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void nlasnapshot_blend_get_inverted_upper_snapshot(NlaEvalData *eval_data,
|
|
|
|
|
NlaEvalSnapshot *lower_snapshot,
|
|
|
|
|
NlaEvalSnapshot *blended_snapshot,
|
|
|
|
|
const short upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalSnapshot *r_upper_snapshot)
|
|
|
|
|
{
|
|
|
|
|
nlaeval_snapshot_ensure_size(r_upper_snapshot, eval_data->num_channels);
|
2021-02-03 16:23:18 -05:00
|
|
|
|
2021-05-11 16:04:18 -04:00
|
|
|
LISTBASE_FOREACH (NlaEvalChannel *, nec, &eval_data->channels) {
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs = nlaeval_snapshot_get(blended_snapshot, nec->index);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (blended_necs == nullptr) {
|
2021-05-11 16:04:18 -04:00
|
|
|
/** We assume the caller only wants a subset of channels to be inverted, those that exist
|
|
|
|
|
* within \a blended_snapshot. */
|
2021-02-03 16:23:18 -05:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-11 16:04:18 -04:00
|
|
|
NlaEvalChannelSnapshot *lower_necs = nlaeval_snapshot_get(lower_snapshot, nec->index);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (lower_necs == nullptr) {
|
2021-05-11 16:04:18 -04:00
|
|
|
lower_necs = nlaeval_snapshot_find_channel(lower_snapshot->base, nec);
|
2021-02-03 16:23:18 -05:00
|
|
|
}
|
2021-02-16 23:58:29 -05:00
|
|
|
|
2021-05-11 16:04:18 -04:00
|
|
|
NlaEvalChannelSnapshot *result_necs = nlaeval_snapshot_ensure_channel(r_upper_snapshot, nec);
|
|
|
|
|
nlaevalchan_blendOrcombine_get_inverted_upper_evalchan(
|
|
|
|
|
lower_necs, blended_necs, upper_blendmode, upper_influence, result_necs);
|
2021-02-03 16:23:18 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
void nlasnapshot_blend_get_inverted_lower_snapshot(NlaEvalData *eval_data,
|
|
|
|
|
NlaEvalSnapshot *blended_snapshot,
|
|
|
|
|
NlaEvalSnapshot *upper_snapshot,
|
|
|
|
|
const short upper_blendmode,
|
|
|
|
|
const float upper_influence,
|
|
|
|
|
NlaEvalSnapshot *r_lower_snapshot)
|
|
|
|
|
{
|
|
|
|
|
nlaeval_snapshot_ensure_size(r_lower_snapshot, eval_data->num_channels);
|
|
|
|
|
|
|
|
|
|
LISTBASE_FOREACH (NlaEvalChannel *, nec, &eval_data->channels) {
|
|
|
|
|
NlaEvalChannelSnapshot *blended_necs = nlaeval_snapshot_get(blended_snapshot, nec->index);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (blended_necs == nullptr) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* We assume the caller only wants a subset of channels to be inverted, those that exist
|
|
|
|
|
* within \a blended_snapshot. */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
NlaEvalChannelSnapshot *upper_necs = nlaeval_snapshot_get(upper_snapshot, nec->index);
|
|
|
|
|
NlaEvalChannelSnapshot *result_necs = nlaeval_snapshot_ensure_channel(r_lower_snapshot, nec);
|
|
|
|
|
|
|
|
|
|
nlaevalchan_blendOrCombine_get_inverted_lower_evalchan(
|
|
|
|
|
blended_necs, upper_necs, upper_blendmode, upper_influence, result_necs);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-03 16:23:18 -05:00
|
|
|
/* ---------------------- */
|
|
|
|
|
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
NlaKeyframingContext *BKE_animsys_get_nla_keyframing_context(
|
2023-06-03 08:36:28 +10:00
|
|
|
ListBase *cache, PointerRNA *ptr, AnimData *adt, const AnimationEvalContext *anim_eval_context)
|
2018-11-12 19:41:53 +03:00
|
|
|
{
|
|
|
|
|
/* No remapping needed if NLA is off or no action. */
|
2023-07-17 10:46:26 +02:00
|
|
|
if ((adt == nullptr) || (adt->action == nullptr) || (adt->nla_tracks.first == nullptr) ||
|
2018-11-12 19:41:53 +03:00
|
|
|
(adt->flag & ADT_NLA_EVAL_OFF))
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* No remapping if editing an ordinary Replace action with full influence and upper tracks not
|
|
|
|
|
* evaluated. */
|
2018-11-12 19:41:53 +03:00
|
|
|
if (!(adt->flag & ADT_NLA_EDIT_ON) &&
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
(adt->act_blendmode == NLASTRIP_MODE_REPLACE && adt->act_influence == 1.0f) &&
|
|
|
|
|
(adt->flag & ADT_NLA_EVAL_UPPER_TRACKS) == 0)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Try to find a cached context. */
|
2023-07-17 10:46:26 +02:00
|
|
|
NlaKeyframingContext *ctx = static_cast<NlaKeyframingContext *>(
|
|
|
|
|
BLI_findptr(cache, adt, offsetof(NlaKeyframingContext, adt)));
|
2018-11-12 19:41:53 +03:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ctx == nullptr) {
|
2018-11-12 19:41:53 +03:00
|
|
|
/* Allocate and evaluate a new context. */
|
2023-07-17 10:46:26 +02:00
|
|
|
ctx = static_cast<NlaKeyframingContext *>(MEM_callocN(sizeof(*ctx), "NlaKeyframingContext"));
|
2018-11-12 19:41:53 +03:00
|
|
|
ctx->adt = adt;
|
|
|
|
|
|
2020-12-21 13:58:36 -05:00
|
|
|
nlaeval_init(&ctx->lower_eval_data);
|
2021-01-14 18:25:01 -05:00
|
|
|
animsys_evaluate_nla_for_keyframing(ptr, adt, anim_eval_context, ctx);
|
2018-11-12 19:41:53 +03:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_assert(ELEM(ctx->strip.act, nullptr, adt->action));
|
2018-11-12 19:41:53 +03:00
|
|
|
BLI_addtail(cache, ctx);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ctx;
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-03 08:36:28 +10:00
|
|
|
void BKE_animsys_nla_remap_keyframe_values(NlaKeyframingContext *context,
|
|
|
|
|
PointerRNA *prop_ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2023-10-24 09:01:38 +02:00
|
|
|
const blender::MutableSpan<float> values,
|
2019-01-08 18:49:38 +03:00
|
|
|
int index,
|
2023-06-03 08:36:28 +10:00
|
|
|
const AnimationEvalContext *anim_eval_context,
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
bool *r_force_all,
|
|
|
|
|
BLI_bitmap *r_successful_remaps)
|
2018-11-12 19:41:53 +03:00
|
|
|
{
|
2023-10-24 09:01:38 +02:00
|
|
|
const int count = values.size();
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
BLI_bitmap_set_all(r_successful_remaps, false, count);
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (r_force_all != nullptr) {
|
2019-01-08 18:49:38 +03:00
|
|
|
*r_force_all = false;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
BLI_bitmap *remap_domain = BLI_BITMAP_NEW(count, __func__);
|
|
|
|
|
for (int i = 0; i < count; i++) {
|
|
|
|
|
if (!ELEM(index, i, -1)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_BITMAP_ENABLE(remap_domain, i);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-12 19:41:53 +03:00
|
|
|
/* No context means no correction. */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (context == nullptr || context->strip.act == nullptr) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
BLI_bitmap_copy_all(r_successful_remaps, remap_domain, count);
|
|
|
|
|
MEM_freeN(remap_domain);
|
|
|
|
|
return;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-11-12 19:41:53 +03:00
|
|
|
/* If the strip is not evaluated, it is the same as zero influence. */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (context->eval_strip == nullptr) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
MEM_freeN(remap_domain);
|
|
|
|
|
return;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* Full influence Replace strips also require no correction if there are no upper tracks
|
|
|
|
|
* evaluating. */
|
2018-11-12 19:41:53 +03:00
|
|
|
int blend_mode = context->strip.blendmode;
|
|
|
|
|
float influence = context->strip.influence;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
if (blend_mode == NLASTRIP_MODE_REPLACE && influence == 1.0f &&
|
|
|
|
|
BLI_listbase_is_empty(&context->upper_estrips))
|
|
|
|
|
{
|
|
|
|
|
BLI_bitmap_copy_all(r_successful_remaps, remap_domain, count);
|
|
|
|
|
MEM_freeN(remap_domain);
|
|
|
|
|
return;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-11-12 19:41:53 +03:00
|
|
|
/* Zero influence is division by zero. */
|
|
|
|
|
if (influence <= 0.0f) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
MEM_freeN(remap_domain);
|
|
|
|
|
return;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-05-11 16:04:18 -04:00
|
|
|
/** Create \a blended_snapshot and fill with input \a values. */
|
|
|
|
|
NlaEvalData *eval_data = &context->lower_eval_data;
|
|
|
|
|
NlaEvalSnapshot blended_snapshot;
|
2023-07-17 10:46:26 +02:00
|
|
|
nlaeval_snapshot_init(&blended_snapshot, eval_data, nullptr);
|
2021-05-11 16:04:18 -04:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
NlaEvalChannelKey key{};
|
|
|
|
|
key.ptr = *prop_ptr;
|
|
|
|
|
key.prop = prop;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
NlaEvalChannel *nec = nlaevalchan_verify_key(eval_data, nullptr, &key);
|
2021-05-11 16:04:18 -04:00
|
|
|
BLI_assert(nec);
|
|
|
|
|
if (nec->base_snapshot.length != count) {
|
2021-07-15 18:23:28 +10:00
|
|
|
BLI_assert_msg(0, "invalid value count");
|
2021-05-11 16:04:18 -04:00
|
|
|
nlaeval_snapshot_free_data(&blended_snapshot);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
MEM_freeN(remap_domain);
|
|
|
|
|
return;
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-05-11 16:04:18 -04:00
|
|
|
NlaEvalChannelSnapshot *blended_necs = nlaeval_snapshot_ensure_channel(&blended_snapshot, nec);
|
2023-10-24 09:01:38 +02:00
|
|
|
std::copy(values.begin(), values.end(), blended_necs->values);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
|
2023-03-20 15:07:50 +01:00
|
|
|
/* Force all channels to be remapped for quaternions in a Combine or Replace strip, otherwise it
|
|
|
|
|
* will always fail. See nlaevalchan_combine_quaternion_handle_undefined_blend_values().
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
*/
|
2023-07-17 10:46:26 +02:00
|
|
|
const bool can_force_all = r_force_all != nullptr;
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
if (blended_necs->channel->mix_mode == NEC_MIX_QUATERNION &&
|
2023-03-20 15:07:50 +01:00
|
|
|
ELEM(blend_mode, NLASTRIP_MODE_COMBINE, NLASTRIP_MODE_REPLACE) && can_force_all)
|
|
|
|
|
{
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
|
|
|
|
|
*r_force_all = true;
|
|
|
|
|
index = -1;
|
|
|
|
|
BLI_bitmap_set_all(remap_domain, true, 4);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_bitmap_copy_all(blended_necs->remap_domain.ptr, remap_domain, count);
|
|
|
|
|
|
|
|
|
|
/* Need to send id_ptr instead of prop_ptr so fcurve RNA paths resolve properly. */
|
2023-09-06 00:48:50 +02:00
|
|
|
PointerRNA id_ptr = RNA_id_pointer_create(prop_ptr->owner_id);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
|
|
|
|
|
/* Per iteration, remove effect of upper strip which gives output of nla stack below it. */
|
|
|
|
|
LISTBASE_FOREACH_BACKWARD (NlaEvalStrip *, nes, &context->upper_estrips) {
|
|
|
|
|
/* This will disable blended_necs->remap_domain bits if an upper strip is not invertible
|
|
|
|
|
* (full replace, multiply zero, or transition). Then there is no remap solution. */
|
|
|
|
|
nlasnapshot_blend_strip_get_inverted_lower_snapshot(
|
2023-07-17 10:46:26 +02:00
|
|
|
&id_ptr, eval_data, nullptr, nes, &blended_snapshot, anim_eval_context);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-05-11 16:04:18 -04:00
|
|
|
/** Remove lower NLA stack effects. */
|
|
|
|
|
nlasnapshot_blend_get_inverted_upper_snapshot(eval_data,
|
|
|
|
|
&context->lower_eval_data.eval_snapshot,
|
|
|
|
|
&blended_snapshot,
|
|
|
|
|
blend_mode,
|
|
|
|
|
influence,
|
|
|
|
|
&blended_snapshot);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
/* Write results into \a values for successfully remapped values. */
|
2021-05-11 16:04:18 -04:00
|
|
|
for (int i = 0; i < count; i++) {
|
|
|
|
|
if (!BLI_BITMAP_TEST_BOOL(blended_necs->remap_domain.ptr, i)) {
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
continue;
|
2019-01-08 18:49:38 +03:00
|
|
|
}
|
2021-05-11 16:04:18 -04:00
|
|
|
values[i] = blended_necs->values[i];
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
BLI_bitmap_copy_all(r_successful_remaps, blended_necs->remap_domain.ptr, blended_necs->length);
|
2021-05-11 16:04:18 -04:00
|
|
|
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
nlaeval_snapshot_free_data(&blended_snapshot);
|
|
|
|
|
MEM_freeN(remap_domain);
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
|
|
|
|
|
2023-06-03 08:36:28 +10:00
|
|
|
void BKE_animsys_free_nla_keyframing_context_cache(ListBase *cache)
|
2018-11-12 19:41:53 +03:00
|
|
|
{
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (NlaKeyframingContext *, ctx, cache) {
|
2018-11-12 19:41:53 +03:00
|
|
|
MEM_SAFE_FREE(ctx->eval_strip);
|
NLA: Keyframe Remap Through Upper Strips
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
2022-04-14 11:38:36 +02:00
|
|
|
BLI_freelistN(&ctx->upper_estrips);
|
2020-12-21 13:58:36 -05:00
|
|
|
nlaeval_free(&ctx->lower_eval_data);
|
2018-11-12 19:41:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_freelistN(cache);
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* ***************************************** */
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* Overrides System - Public API */
|
|
|
|
|
|
|
|
|
|
/* Evaluate Overrides */
|
2012-05-12 16:11:34 +00:00
|
|
|
static void animsys_evaluate_overrides(PointerRNA *ptr, AnimData *adt)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
|
|
|
|
/* for each override, simply execute... */
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (AnimOverride *, aor, &adt->overrides) {
|
2016-07-30 16:34:01 +10:00
|
|
|
PathResolvedRNA anim_rna;
|
2021-03-01 18:42:48 +01:00
|
|
|
if (BKE_animsys_rna_path_resolve(ptr, aor->rna_path, aor->array_index, &anim_rna)) {
|
|
|
|
|
BKE_animsys_write_to_rna_path(&anim_rna, aor->value);
|
2016-07-30 16:34:01 +10:00
|
|
|
}
|
|
|
|
|
}
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ***************************************** */
|
|
|
|
|
/* Evaluation System - Public API */
|
|
|
|
|
|
|
|
|
|
/* Overview of how this system works:
|
2018-11-14 12:53:15 +11:00
|
|
|
* 1) Depsgraph sorts data as necessary, so that data is in an order that means
|
|
|
|
|
* that all dependencies are resolved before dependents.
|
|
|
|
|
* 2) All normal animation is evaluated, so that drivers have some basis values to
|
|
|
|
|
* work with
|
|
|
|
|
* a. NLA stacks are done first, as the Active Actions act as 'tweaking' tracks
|
|
|
|
|
* which modify the effects of the NLA-stacks
|
|
|
|
|
* b. Active Action is evaluated as per normal, on top of the results of the NLA tracks
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*
|
2018-06-01 18:19:39 +02:00
|
|
|
* --------------< often in a separate phase... >------------------
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*
|
2018-11-14 12:53:15 +11:00
|
|
|
* 3) Drivers/expressions are evaluated on top of this, in an order where dependencies are
|
|
|
|
|
* resolved nicely.
|
2021-07-03 23:08:40 +10:00
|
|
|
* NOTE: it may be necessary to have some tools to handle the cases where some higher-level
|
2019-04-27 12:07:07 +10:00
|
|
|
* drivers are added and cause some problematic dependencies that
|
|
|
|
|
* didn't exist in the local levels...
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*
|
2018-06-01 18:19:39 +02:00
|
|
|
* --------------< always executed >------------------
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*
|
2012-03-01 12:20:18 +00:00
|
|
|
* Maintenance of editability of settings (XXX):
|
2019-04-27 12:07:07 +10:00
|
|
|
* - In order to ensure that settings that are animated can still be manipulated in the UI without
|
|
|
|
|
* requiring that keyframes are added to prevent these values from being overwritten,
|
|
|
|
|
* we use 'overrides'.
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*
|
|
|
|
|
* Unresolved things:
|
2019-04-27 12:07:07 +10:00
|
|
|
* - Handling of multi-user settings (i.e. time-offset, group-instancing) -> big cache grids
|
|
|
|
|
* or nodal system? but stored where?
|
|
|
|
|
* - Multiple-block dependencies
|
|
|
|
|
* (i.e. drivers for settings are in both local and higher levels) -> split into separate lists?
|
2009-09-30 04:59:14 +00:00
|
|
|
*
|
|
|
|
|
* Current Status:
|
2018-11-14 12:53:15 +11:00
|
|
|
* - Currently (as of September 2009), overrides we haven't needed to (fully) implement overrides.
|
|
|
|
|
* However, the code for this is relatively harmless, so is left in the code for now.
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*/
|
|
|
|
|
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
void BKE_animsys_evaluate_animdata(ID *id,
|
|
|
|
|
AnimData *adt,
|
|
|
|
|
const AnimationEvalContext *anim_eval_context,
|
|
|
|
|
eAnimData_Recalc recalc,
|
|
|
|
|
const bool flush_to_original)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* sanity checks */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (ELEM(nullptr, id, adt)) {
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* get pointer to ID-block for RNA to use */
|
2023-09-06 00:48:50 +02:00
|
|
|
PointerRNA id_ptr = RNA_id_pointer_create(id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* recalculate keyframe data:
|
2018-11-14 12:53:15 +11:00
|
|
|
* - NLA before Active Action, as Active Action behaves as 'tweaking track'
|
|
|
|
|
* that overrides 'rough' work in NLA
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*/
|
2012-07-06 23:56:59 +00:00
|
|
|
/* TODO: need to double check that this all works correctly */
|
2019-01-29 11:59:17 +01:00
|
|
|
if (recalc & ADT_RECALC_ANIM) {
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* evaluate NLA data */
|
2012-03-07 04:53:43 +00:00
|
|
|
if ((adt->nla_tracks.first) && !(adt->flag & ADT_NLA_EVAL_OFF)) {
|
2018-06-17 17:05:51 +02:00
|
|
|
/* evaluate NLA-stack
|
2018-11-14 12:53:15 +11:00
|
|
|
* - active action is evaluated as part of the NLA stack as the last item
|
2009-06-05 11:51:27 +00:00
|
|
|
*/
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
animsys_calculate_nla(&id_ptr, adt, anim_eval_context, flush_to_original);
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
2009-06-05 11:51:27 +00:00
|
|
|
/* evaluate Active Action only */
|
2019-04-22 09:39:35 +10:00
|
|
|
else if (adt->action) {
|
2021-03-01 17:37:26 +01:00
|
|
|
animsys_evaluate_action(&id_ptr, adt->action, anim_eval_context, flush_to_original);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* recalculate drivers
|
2018-11-14 12:53:15 +11:00
|
|
|
* - Drivers need to be evaluated afterwards, as they can either override
|
|
|
|
|
* or be layered on top of existing animation data.
|
|
|
|
|
* - Drivers should be in the appropriate order to be evaluated without problems...
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*/
|
2019-01-29 11:59:17 +01:00
|
|
|
if (recalc & ADT_RECALC_DRIVERS) {
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
animsys_evaluate_drivers(&id_ptr, adt, anim_eval_context);
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* always execute 'overrides'
|
2018-11-14 12:53:15 +11:00
|
|
|
* - Overrides allow editing, by overwriting the value(s) set from animation-data, with the
|
|
|
|
|
* value last set by the user (and not keyframed yet).
|
|
|
|
|
* - Overrides are cleared upon frame change and/or keyframing
|
|
|
|
|
* - It is best that we execute this every time, so that no errors are likely to occur.
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
*/
|
2010-10-16 08:03:28 +00:00
|
|
|
animsys_evaluate_overrides(&id_ptr, adt);
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
2020-04-16 11:05:52 +10:00
|
|
|
void BKE_animsys_evaluate_all_animation(Main *main, Depsgraph *depsgraph, float ctime)
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
{
|
|
|
|
|
ID *id;
|
2011-03-27 23:11:22 +00:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (G.debug & G_DEBUG) {
|
2012-03-31 00:59:17 +00:00
|
|
|
printf("Evaluate all animation - %f\n", ctime);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2019-07-31 18:20:18 +02:00
|
|
|
const bool flush_to_original = DEG_is_active(depsgraph);
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const AnimationEvalContext anim_eval_context = BKE_animsys_eval_context_construct(depsgraph,
|
|
|
|
|
ctime);
|
2019-07-31 14:56:17 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
/* macros for less typing
|
|
|
|
|
* - only evaluate animation data for id if it has users (and not just fake ones)
|
|
|
|
|
* - whether animdata exists is checked for by the evaluation function, though taking
|
|
|
|
|
* this outside of the function may make things slightly faster?
|
|
|
|
|
*/
|
2009-08-02 11:05:13 +00:00
|
|
|
#define EVAL_ANIM_IDS(first, aflag) \
|
2023-07-17 10:46:26 +02:00
|
|
|
for (id = static_cast<ID *>(first); id; id = static_cast<ID *>(id->next)) { \
|
2010-05-13 09:22:05 +00:00
|
|
|
if (ID_REAL_USERS(id) > 0) { \
|
2012-05-12 16:11:34 +00:00
|
|
|
AnimData *adt = BKE_animdata_from_id(id); \
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
BKE_animsys_evaluate_animdata(id, adt, &anim_eval_context, aflag, flush_to_original); \
|
2010-05-13 09:22:05 +00:00
|
|
|
} \
|
2012-05-27 20:13:59 +00:00
|
|
|
} \
|
|
|
|
|
(void)0
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
/* Another macro for the "embedded" node-tree cases
|
|
|
|
|
* - This is like #EVAL_ANIM_IDS, but this handles the case "embedded node-trees"
|
|
|
|
|
* (i.e. `scene/material/texture->nodetree`) which we need a special exception
|
|
|
|
|
* for, otherwise they'd get skipped.
|
|
|
|
|
* - `ntp` stands for "node tree parent" = data-block where node tree stuff resides.
|
|
|
|
|
*/
|
2010-11-22 23:59:00 +00:00
|
|
|
#define EVAL_ANIM_NODETREE_IDS(first, NtId_Type, aflag) \
|
2023-07-17 10:46:26 +02:00
|
|
|
for (id = static_cast<ID *>(first); id; id = static_cast<ID *>(id->next)) { \
|
2010-11-22 23:59:00 +00:00
|
|
|
if (ID_REAL_USERS(id) > 0) { \
|
2012-05-12 16:11:34 +00:00
|
|
|
AnimData *adt = BKE_animdata_from_id(id); \
|
|
|
|
|
NtId_Type *ntp = (NtId_Type *)id; \
|
2010-11-22 23:59:00 +00:00
|
|
|
if (ntp->nodetree) { \
|
2012-05-12 16:11:34 +00:00
|
|
|
AnimData *adt2 = BKE_animdata_from_id((ID *)ntp->nodetree); \
|
2018-05-31 12:52:13 +02:00
|
|
|
BKE_animsys_evaluate_animdata( \
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
&ntp->nodetree->id, adt2, &anim_eval_context, ADT_RECALC_ANIM, flush_to_original); \
|
2010-11-22 23:59:00 +00:00
|
|
|
} \
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
BKE_animsys_evaluate_animdata(id, adt, &anim_eval_context, aflag, flush_to_original); \
|
2019-04-17 06:17:24 +02:00
|
|
|
} \
|
2010-11-22 23:59:00 +00:00
|
|
|
} \
|
2012-05-27 20:13:59 +00:00
|
|
|
(void)0
|
2018-06-17 17:05:51 +02:00
|
|
|
|
|
|
|
|
/* optimization:
|
2019-06-12 09:04:10 +10:00
|
|
|
* when there are no actions, don't go over database and loop over heaps of data-blocks,
|
2018-06-17 17:05:51 +02:00
|
|
|
* which should ultimately be empty, since it is not possible for now to have any animation
|
2009-08-02 11:05:13 +00:00
|
|
|
* without some actions, and drivers wouldn't get affected by any state changes
|
2009-09-11 00:49:54 +00:00
|
|
|
*
|
|
|
|
|
* however, if there are some curves, we will need to make sure that their 'ctime' property gets
|
2012-03-02 16:05:54 +00:00
|
|
|
* set correctly, so this optimization must be skipped in that case...
|
2009-08-02 11:05:13 +00:00
|
|
|
*/
|
2019-03-08 09:29:17 +11:00
|
|
|
if (BLI_listbase_is_empty(&main->actions) && BLI_listbase_is_empty(&main->curves)) {
|
2019-04-22 09:39:35 +10:00
|
|
|
if (G.debug & G_DEBUG) {
|
2009-08-02 11:05:13 +00:00
|
|
|
printf("\tNo Actions, so no animation needs to be evaluated...\n");
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-08-02 11:05:13 +00:00
|
|
|
return;
|
2009-01-18 10:41:45 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* nodes */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->nodetrees.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* textures */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_NODETREE_IDS(main->textures.first, Tex, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2019-02-27 12:02:02 +11:00
|
|
|
/* lights */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_NODETREE_IDS(main->lights.first, Light, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* materials */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_NODETREE_IDS(main->materials.first, Material, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* cameras */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->cameras.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* shapekeys */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->shapekeys.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-08-03 13:09:23 +00:00
|
|
|
/* metaballs */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->metaballs.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* curves */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->curves.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-09-21 06:43:20 +00:00
|
|
|
/* armatures */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->armatures.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2010-12-13 06:31:49 +00:00
|
|
|
/* lattices */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->lattices.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* meshes */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->meshes.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-06-24 02:11:36 +00:00
|
|
|
/* particles */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->particles.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2011-11-03 10:03:08 +00:00
|
|
|
/* speakers */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->speakers.first, ADT_RECALC_ANIM);
|
2011-08-01 11:44:20 +00:00
|
|
|
|
2012-02-17 08:13:45 +00:00
|
|
|
/* movie clips */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->movieclips.first, ADT_RECALC_ANIM);
|
2012-02-17 08:13:45 +00:00
|
|
|
|
2010-06-25 22:45:42 +00:00
|
|
|
/* linestyles */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->linestyles.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
Grease Pencil - Storyboarding Features (merge from GPencil_EditStrokes branch)
This merge-commit brings in a number of new features and workflow/UI improvements for
working with Grease Pencil. While these were originally targetted at improving
the workflow for creating 3D storyboards in Blender using the Grease Pencil,
many of these changes should also prove useful in other workflows too.
The main highlights here are:
1) It is now possible to edit Grease Pencil strokes
- Use D Tab, or toggle the "Enable Editing" toggles in the Toolbar/Properties regions
to enter "Stroke Edit Mode". In this mode, many common editing tools will
operate on Grease Pencil stroke points instead.
- Tools implemented include Select, Select All/Border/Circle/Linked/More/Less,
Grab, Rotate, Scale, Bend, Shear, To Sphere, Mirror, Duplicate, Delete.
- Proportional Editing works when using the transform tools
2) Grease Pencil stroke settings can now be animated
NOTE: Currently drivers don't work, but if time allows, this may still be
added before the release.
3) Strokes can be drawn with "filled" interiors, using a separate set of
colour/opacity settings to the ones used for the lines themselves.
This makes use of OpenGL filled polys, which has the limitation of only
being able to fill convex shapes. Some artifacts may be visible on concave
shapes (e.g. pacman's mouth will be overdrawn)
4) "Volumetric Strokes" - An alternative drawing technique for stroke drawing
has been added which draws strokes as a series of screen-aligned discs.
While this was originally a partial experimental technique at getting better
quality 3D lines, the effects possible using this technique were interesting
enough to warrant making this a dedicated feature. Best results when partial
opacity and large stroke widths are used.
5) Improved Onion Skinning Support
- Different colours can be selected for the before/after ghosts. To do so,
enable the "colour wheel" toggle beside the Onion Skinning toggle, and set
the colours accordingly.
- Different numbers of ghosts can be shown before/after the current frame
6) Grease Pencil datablocks are now attached to the scene by default instead of
the active object.
- For a long time, the object-attachment has proved to be quite problematic
for users to keep track of. Now that this is done at scene level, it is
easier for most users to use.
- An exception for old files (and for any addons which may benefit from object
attachment instead), is that if the active object has a Grease Pencil datablock,
that will be used instead.
- It is not currently possible to choose object-attachment from the UI, but
it is simple to do this from the console instead, by doing:
context.active_object.grease_pencil = bpy.data.grease_pencil["blah"]
7) Various UI Cleanups
- The layers UI has been cleaned up to use a list instead of the nested-panels
design. Apart from saving space, this is also much nicer to look at now.
- The UI code is now all defined in Python. To support this, it has been necessary
to add some new context properties to make it easier to access these settings.
e.g. "gpencil_data" for the datablock
"active_gpencil_layer" and "active_gpencil_frame" for active data,
"editable_gpencil_strokes" for the strokes that can be edited
- The "stroke placement/alignment" settings (previously "Drawing Settings" at the
bottom of the Grease Pencil panel in the Properties Region) is now located in
the toolbar. These were more toolsettings than properties for how GPencil got drawn.
- "Use Sketching Sessions" has been renamed "Continuous Drawing", as per a
suggestion for an earlier discussion on developer.blender.org
- By default, the painting operator will wait for a mouse button to be pressed
before it starts creating the stroke. This is to make it easier to include
this operator in various toolbars/menus/etc. To get it immediately starting
(as when you hold down DKEy to draw), set "wait_for_input" to False.
- GPencil Layers can be rearranged in the "Grease Pencil" mode of the Action Editor
- Toolbar panels have been added to all the other editors which support these.
8) Pie menus for quick-access to tools
A set of experimental pie menus has been included for quick access to many
tools and settings. It is not necessary to use these to get things done,
but they have been designed to help make certain common tasks easier.
- Ctrl-D = The main pie menu. Reveals tools in a context sensitive and
spatially stable manner.
- D Q = "Quick Settings" pie. This allows quick access to the active
layer's settings. Notably, colours, thickness, and turning
onion skinning on/off.
2014-12-01 01:52:06 +13:00
|
|
|
/* grease pencil */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->gpencils.first, ADT_RECALC_ANIM);
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
|
2018-07-31 10:22:19 +02:00
|
|
|
/* palettes */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->palettes.first, ADT_RECALC_ANIM);
|
2018-07-31 10:22:19 +02:00
|
|
|
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
/* cache files */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->cachefiles.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
Curves: Rename "Hair" types, variables, and functions to "Curves"
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
2022-02-07 11:55:54 -06:00
|
|
|
/* Hair Curves. */
|
|
|
|
|
EVAL_ANIM_IDS(main->hair_curves.first, ADT_RECALC_ANIM);
|
2020-03-17 14:41:48 +01:00
|
|
|
|
|
|
|
|
/* pointclouds */
|
|
|
|
|
EVAL_ANIM_IDS(main->pointclouds.first, ADT_RECALC_ANIM);
|
|
|
|
|
|
|
|
|
|
/* volumes */
|
|
|
|
|
EVAL_ANIM_IDS(main->volumes.first, ADT_RECALC_ANIM);
|
|
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* objects */
|
2012-05-12 16:11:34 +00:00
|
|
|
/* ADT_RECALC_ANIM doesn't need to be supplied here, since object AnimData gets
|
2022-06-03 13:39:37 +10:00
|
|
|
* this tagged by Depsgraph on frame-change. This optimization means that objects
|
2012-05-12 16:11:34 +00:00
|
|
|
* linked from other (not-visible) scenes will not need their data calculated.
|
|
|
|
|
*/
|
2023-07-17 10:46:26 +02:00
|
|
|
EVAL_ANIM_IDS(main->objects.first, eAnimData_Recalc(0));
|
2012-06-04 16:42:58 +00:00
|
|
|
|
|
|
|
|
/* masks */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_IDS(main->masks.first, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* worlds */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_NODETREE_IDS(main->worlds.first, World, ADT_RECALC_ANIM);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* scenes */
|
2019-03-08 09:29:17 +11:00
|
|
|
EVAL_ANIM_NODETREE_IDS(main->scenes.first, Scene, ADT_RECALC_ANIM);
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
2018-06-17 17:05:51 +02:00
|
|
|
/* ***************************************** */
|
2015-05-12 13:57:11 +05:00
|
|
|
|
|
|
|
|
/* ************** */
|
|
|
|
|
/* Evaluation API */
|
|
|
|
|
|
2018-04-06 12:07:27 +02:00
|
|
|
void BKE_animsys_eval_animdata(Depsgraph *depsgraph, ID *id)
|
2015-05-12 13:57:11 +05:00
|
|
|
{
|
2018-04-06 12:07:27 +02:00
|
|
|
float ctime = DEG_get_ctime(depsgraph);
|
2015-05-12 13:57:11 +05:00
|
|
|
AnimData *adt = BKE_animdata_from_id(id);
|
2019-04-18 07:21:26 +02:00
|
|
|
/* XXX: this is only needed for flushing RNA updates,
|
|
|
|
|
* which should get handled as part of the dependency graph instead. */
|
2018-05-02 11:46:56 +02:00
|
|
|
DEG_debug_print_eval_time(depsgraph, __func__, id->name, id, ctime);
|
2019-07-31 14:56:17 +02:00
|
|
|
const bool flush_to_original = DEG_is_active(depsgraph);
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
|
|
|
|
|
const AnimationEvalContext anim_eval_context = BKE_animsys_eval_context_construct(depsgraph,
|
|
|
|
|
ctime);
|
|
|
|
|
BKE_animsys_evaluate_animdata(id, adt, &anim_eval_context, ADT_RECALC_ANIM, flush_to_original);
|
2015-05-12 13:57:11 +05:00
|
|
|
}
|
|
|
|
|
|
2018-05-31 06:04:25 +02:00
|
|
|
void BKE_animsys_update_driver_array(ID *id)
|
2018-03-14 15:19:44 +01:00
|
|
|
{
|
2018-05-31 06:04:25 +02:00
|
|
|
AnimData *adt = BKE_animdata_from_id(id);
|
|
|
|
|
|
|
|
|
|
/* Runtime driver map to avoid O(n^2) lookups in BKE_animsys_eval_driver.
|
|
|
|
|
* Ideally the depsgraph could pass a pointer to the COW driver directly,
|
|
|
|
|
* but this is difficult in the current design. */
|
|
|
|
|
if (adt && adt->drivers.first) {
|
|
|
|
|
BLI_assert(!adt->driver_array);
|
|
|
|
|
|
|
|
|
|
int num_drivers = BLI_listbase_count(&adt->drivers);
|
2023-07-17 10:46:26 +02:00
|
|
|
adt->driver_array = static_cast<FCurve **>(
|
|
|
|
|
MEM_mallocN(sizeof(FCurve *) * num_drivers, "adt->driver_array"));
|
2018-05-31 06:04:25 +02:00
|
|
|
|
|
|
|
|
int driver_index = 0;
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (FCurve *, fcu, &adt->drivers) {
|
2018-05-31 06:04:25 +02:00
|
|
|
adt->driver_array[driver_index++] = fcu;
|
|
|
|
|
}
|
2018-03-14 15:19:44 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-25 10:31:34 +02:00
|
|
|
void BKE_animsys_eval_driver(Depsgraph *depsgraph, ID *id, int driver_index, FCurve *fcu_orig)
|
2015-05-12 13:57:11 +05:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
BLI_assert(fcu_orig != nullptr);
|
2019-09-25 10:31:34 +02:00
|
|
|
|
2015-05-12 13:57:11 +05:00
|
|
|
/* TODO(sergey): De-duplicate with BKE animsys. */
|
|
|
|
|
bool ok = false;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-31 06:04:25 +02:00
|
|
|
/* Lookup driver, accelerated with driver array map. */
|
|
|
|
|
const AnimData *adt = BKE_animdata_from_id(id);
|
2018-06-01 18:10:43 +02:00
|
|
|
FCurve *fcu;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-31 06:04:25 +02:00
|
|
|
if (adt->driver_array) {
|
|
|
|
|
fcu = adt->driver_array[driver_index];
|
|
|
|
|
}
|
|
|
|
|
else {
|
2023-07-17 10:46:26 +02:00
|
|
|
fcu = static_cast<FCurve *>(BLI_findlink(&adt->drivers, driver_index));
|
2018-05-31 06:04:25 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-03-16 11:14:38 +01:00
|
|
|
DEG_debug_print_eval_subdata_index(
|
2018-05-02 11:46:56 +02:00
|
|
|
depsgraph, __func__, id->name, id, "fcu", fcu->rna_path, fcu, fcu->array_index);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-09-06 00:48:50 +02:00
|
|
|
PointerRNA id_ptr = RNA_id_pointer_create(id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-05-12 13:57:11 +05:00
|
|
|
/* check if this driver's curve should be skipped */
|
|
|
|
|
if ((fcu->flag & (FCURVE_MUTED | FCURVE_DISABLED)) == 0) {
|
|
|
|
|
/* check if driver itself is tagged for recalculation */
|
|
|
|
|
/* XXX driver recalc flag is not set yet by depsgraph! */
|
2019-09-25 10:31:34 +02:00
|
|
|
ChannelDriver *driver_orig = fcu_orig->driver;
|
2019-01-29 11:59:17 +01:00
|
|
|
if ((driver_orig) && !(driver_orig->flag & DRIVER_FLAG_INVALID)) {
|
2015-05-12 13:57:11 +05:00
|
|
|
/* evaluate this using values set already in other places
|
2019-04-27 12:07:07 +10:00
|
|
|
* NOTE: for 'layering' option later on, we should check if we should remove old value before
|
|
|
|
|
* adding new to only be done when drivers only changed */
|
2019-05-01 11:09:22 +10:00
|
|
|
// printf("\told val = %f\n", fcu->curval);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-07-30 16:34:01 +10:00
|
|
|
PathResolvedRNA anim_rna;
|
2021-03-01 18:42:48 +01:00
|
|
|
if (BKE_animsys_rna_path_resolve(&id_ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
|
2019-01-04 14:57:09 +13:00
|
|
|
/* Evaluate driver, and write results to COW-domain destination */
|
2018-04-06 12:07:27 +02:00
|
|
|
const float ctime = DEG_get_ctime(depsgraph);
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
const AnimationEvalContext anim_eval_context = BKE_animsys_eval_context_construct(
|
|
|
|
|
depsgraph, ctime);
|
|
|
|
|
const float curval = calculate_fcurve(&anim_rna, fcu, &anim_eval_context);
|
2021-03-01 18:42:48 +01:00
|
|
|
ok = BKE_animsys_write_to_rna_path(&anim_rna, curval);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-02-12 14:37:16 +11:00
|
|
|
/* Flush results & status codes to original data for UI (#59984) */
|
2018-05-31 14:27:37 +02:00
|
|
|
if (ok && DEG_is_active(depsgraph)) {
|
2018-11-12 19:30:25 +03:00
|
|
|
animsys_write_orig_anim_rna(&id_ptr, fcu->rna_path, fcu->array_index, curval);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-04 14:57:09 +13:00
|
|
|
/* curval is displayed in the UI, and flag contains error-status codes */
|
2019-09-25 10:31:34 +02:00
|
|
|
fcu_orig->curval = fcu->curval;
|
2019-01-04 14:57:09 +13:00
|
|
|
driver_orig->curval = fcu->driver->curval;
|
|
|
|
|
driver_orig->flag = fcu->driver->flag;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
DriverVar *dvar_orig = static_cast<DriverVar *>(driver_orig->variables.first);
|
|
|
|
|
DriverVar *dvar = static_cast<DriverVar *>(fcu->driver->variables.first);
|
2019-01-04 14:57:09 +13:00
|
|
|
for (; dvar_orig && dvar; dvar_orig = dvar_orig->next, dvar = dvar->next) {
|
|
|
|
|
DriverTarget *dtar_orig = &dvar_orig->targets[0];
|
|
|
|
|
DriverTarget *dtar = &dvar->targets[0];
|
|
|
|
|
for (int i = 0; i < MAX_DRIVER_TARGETS; i++, dtar_orig++, dtar++) {
|
|
|
|
|
dtar_orig->flag = dtar->flag;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-04 14:57:09 +13:00
|
|
|
dvar_orig->curval = dvar->curval;
|
|
|
|
|
dvar_orig->flag = dvar->flag;
|
|
|
|
|
}
|
2018-05-31 14:27:37 +02:00
|
|
|
}
|
2016-07-30 16:34:01 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-05-12 13:57:11 +05:00
|
|
|
/* set error-flag if evaluation failed */
|
|
|
|
|
if (ok == 0) {
|
2020-08-26 17:48:20 +02:00
|
|
|
CLOG_WARN(&LOG, "invalid driver - %s[%d]", fcu->rna_path, fcu->array_index);
|
2018-05-31 06:04:25 +02:00
|
|
|
driver_orig->flag |= DRIVER_FLAG_INVALID;
|
2015-05-12 13:57:11 +05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|