archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
a261d6f2d3feb80efb51b27aa7cae56ea6c4c57d
blender-archive/source/blender/blenkernel/intern/anim_sys.c

3801 lines
118 KiB
C
Raw Normal View History

doxygen: prevent GPL license block from being parsed as doxygen comment.
2011-02-23 10:52:22 +00:00
/*
NLA SoC: Big Commit - Restored NLA-Mapping Corrections In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :) To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with. I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here... Also, added proper license headers to new NLA files. TODO: - testing + bugfixing due to this commit - show range of keyframes in NLA Editor active-action line
2009-06-23 13:25:31 +00:00
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
correct fsf address
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
NLA SoC: Big Commit - Restored NLA-Mapping Corrections In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :) To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with. I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here... Also, added proper license headers to new NLA files. TODO: - testing + bugfixing due to this commit - show range of keyframes in NLA Editor active-action line
2009-06-23 13:25:31 +00:00
*
* The Original Code is Copyright (C) 2009 Blender Foundation, Joshua Leung
* All rights reserved.
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
*/
doxygen: add newline after \file While \file doesn't need an argument, it can't have another doxy command after it.
2019-02-18 08:08:12 +11:00
/** \file
* \ingroup bke
doxygen: blender/blenkernel tagged.
2011-02-27 20:40: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
#include <stdio.h>
#include <string.h>
Animato - Support for 'BuiltIn' and 'Relative' Keying Sets When inserting keyframes in the 3D-View (support will be extended to other editors in due course) using the IKEY hotkey, the menu which appears will now consist of 3 parts: * 'Active Keying Set' - this option allows you to use the user-defined KeyingSet which is active for the current scene (i.e. the one seen in the TimeLine/Outliner headers) * User defined Keying Sets - a list of all such available KeyingSets is included, and entries can be chosen from there * Built-In Keying Sets - see later... To achieve this, several changes needed to be made first: * Added support for 'relative' in addition to 'absolute' Keying Sets. Relative Keying Sets are Keying Sets which operate on data from the current context (i.e. a 'location' KeyingSet will add location keyframes for selected objects/bones/nodes as opposed to location keyframes for some particular object). The is a tentative 'templates' requirement system here, which still needs to be fully fleshed out. * Added support for builtin Keying Sets (i.e. 'Location', 'Rotation', 'Scaling', and 'LocRot' as a few initial demonstrations), which replaces the temporary Insert Keyframe operator for the 3D-View (IKEY). These are effectively relative Keying Set definitions which are included in Blender by default and stored in a list separate from user-defined ones. Volunteer help in defining a few more of these for other editors will be welcome soon. * Removed/replaced much of the crappy temporary Keyframing operator code, though a few tweaks could still be done.
2009-03-31 22:36:13 +00:00
#include <stddef.h>
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
#include <float.h>
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
#include <math.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 "MEM_guardedalloc.h"
use string escaping when renaming animation paths - BKE_animdata_fix_paths_rename()
2013-04-23 20:24:10 +00: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
#include "BLI_blenlib.h"
move alloca define into its own header since its not related to BLI_array
2013-07-28 10:38:25 +00:00
#include "BLI_alloca.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"
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
#include "BLI_listbase.h"
Cleanup/refactor: Add new BLI_string_util. Things like `BLI_uniquename` had nothing, but really nothing to do in BLI_path_util files! Also, got rid of length limitation in `BLI_uniquename_cb`, we can use alloca here to avoid overhead of malloc while keeping free size (within reasonable limits of course).
2017-01-16 17:33:34 +01:00
#include "BLI_string_utils.h"
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
#include "BLI_math_rotation.h"
#include "BLI_math_vector.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
Refactor translation code out of blenfont - Add blentranslation `BLT_*` module. - moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`). - moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
2015-08-16 17:32:01 +10:00
#include "BLT_translation.h"
More new data names translation (most cases should be covered now). Also done a few cleanup here and there...
2013-03-25 08:29:06 +00:00
NLA SoC: Big Commit - Restored NLA-Mapping Corrections In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :) To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with. I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here... Also, added proper license headers to new NLA files. TODO: - testing + bugfixing due to this commit - show range of keyframes in NLA Editor active-action line
2009-06-23 13:25:31 +00:00
#include "DNA_anim_types.h"
Cleanup: file rename lamp -> light
2019-02-27 12:34:56 +11:00
#include "DNA_light_types.h"
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
#include "DNA_material_types.h"
Fix [#30709] Renaming a bone renames all drivers' targets using a bone of that name, regardless of the armature. This fix adds a "ref_id" ID pointer to BKE_all_animdata_fix_paths_rename() & co, which is the ID against which prefix+oldName/NewName is "applied", currently only used for drivers' bones targets. Just pass NULL to get same behavior as previously. A bit annoying to make such a change for such a specific case, but there seems to be no other way to go... :/
2012-03-30 13:04:29 +00:00
#include "DNA_object_types.h"
2.5 - More Animation Bugfixes * Updating Preview Range settings results in correct updates for Animation Editors * Compositing nodes now correctly animate when the values were set by IKEY/RMB on suitable node parameters. Beware that these nodes are not relinkable node-trees, hence the standard code not working. * Ctrl-P to parent objects to bones now works in Pose Mode too. I needed to add a special keymap entry for this, though I thought this would have been better to be automatically inherited/present from Object keymap already? * Ctrl-P -> Parent to Bone option now works correctly again. 1.5 lines of code missing here... * Breakdowns tool now shows custom cursor during 'modal' phase so that it's not that confusing what's going on.
2009-09-19 12:36:22 +00:00
#include "DNA_scene_types.h"
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
#include "DNA_screen_types.h"
#include "DNA_space_types.h"
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
#include "DNA_texture_types.h"
Nodes: add support for shader nodes on world and lamps, in addition to materials. The internal render engine does not support them, and they are not accesible in the UI yet, but cycles will use them.
2011-11-02 18:55:32 +00:00
#include "DNA_world_types.h"
NLA SoC: Big Commit - Restored NLA-Mapping Corrections In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :) To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with. I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here... Also, added proper license headers to new NLA files. TODO: - testing + bugfixing due to this commit - show range of keyframes in NLA Editor active-action line
2009-06-23 13:25:31 +00:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
#include "BKE_action.h"
Cleanup: remove some useless BKE_library and BKE_main includes. Makes it simpler to make some changes... Also fix order of some includes (use alphabetical please).
2018-11-07 18:00:24 +01:00
#include "BKE_animsys.h"
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
#include "BKE_context.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 "BKE_fcurve.h"
Animato: Hiding all debug prints behind -d flag, as they were causing too many slowdowns on complex rigs with Action Constraints. Many of these prints should eventually be removed, though some of them will still be useful.
2009-01-29 23:27:24 +00:00
#include "BKE_global.h"
Cleanup: remove some useless BKE_library and BKE_main includes. Makes it simpler to make some changes... Also fix order of some includes (use alphabetical please).
2018-11-07 18:00:24 +01:00
#include "BKE_library.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 "BKE_main.h"
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
#include "BKE_material.h"
Cleanup: remove some useless BKE_library and BKE_main includes. Makes it simpler to make some changes... Also fix order of some includes (use alphabetical please).
2018-11-07 18:00:24 +01:00
#include "BKE_nla.h"
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
#include "BKE_report.h"
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
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
Depsgraph: More type definitions to new depsgraph header
2017-04-06 15:37:46 +02:00
#include "DEG_depsgraph.h"
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
#include "DEG_depsgraph_query.h"
Depsgraph: More type definitions to new depsgraph header
2017-04-06 15:37:46 +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
#include "RNA_access.h"
NLA SoC: Big Commit - Restored NLA-Mapping Corrections In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :) To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with. I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here... Also, added proper license headers to new NLA files. TODO: - testing + bugfixing due to this commit - show range of keyframes in NLA Editor active-action line
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
Move ID recalc flags into dedicated field in ID Currently this is a no-visible-changes change, but the idea is to use this dedicated flag to tell which exact components of ID changed, make it more granular than just OBJECT and OBJECT_DATA. Allow setting this field based on what components new dependency graph flushed on evaluation.
2017-12-15 09:43:18 +01:00
#include "atomic_ops.h"
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
#include "CLG_log.h"
static CLG_LogRef LOG = {"bke.anim_sys"};
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
/* ***************************************** */
/* AnimData API */
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* Getter/Setter -------------------------------------------- */
Bugfix #20752: Background Image Panel Properties Keyframing? Added a check in RNA_property_animateable() which checks if the base ID-block can have animation data or not. Screen data currently cannot have animation data, so this solves that problem (where there were non-functional entries there in the menu).
2010-01-27 10:43:14 +00:00
/* Check if ID can have AnimData */
Cleanup/fix animsys 'id_type_can_have_animdata()'. This func now actually takes an ID type as argument, added new 'id_can_have_animdata()' to check whether a datablock may be animated or not.
2016-07-07 20:48:33 +02:00
bool id_type_can_have_animdata(const short id_type)
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
{
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* Only some ID-blocks have this info for now */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: finish adding this for the other blocktypes */
Cleanup/fix animsys 'id_type_can_have_animdata()'. This func now actually takes an ID type as argument, added new 'id_can_have_animdata()' to check whether a datablock may be animated or not.
2016-07-07 20:48:33 +02:00
switch (id_type) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
/* has AnimData */
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
case ID_OB:
Lattices now have AnimData This allows manual (point by point) animation of their control verts, although many other settings cannot really be animated with any visible effects yet. Interestingly, lattices also had IPO block pointers, though they were never really used (AFAIK). Todo: - Animation Editor support has yet to be added. I've got a few other things to add to, so will group those changes together.
2010-12-13 06:31:49 +00:00
case ID_ME: case ID_MB: case ID_CU: case ID_AR: case ID_LT:
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
case ID_KE:
2.5 - Particle Settings now Animateable Added AnimData to ParticleSettings so that this will work. This seems to be ok in the brief tests I did, but be warned that this may not be optimal for the Particles System...
2009-06-24 02:11:36 +00:00
case ID_PA:
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
case ID_MA: case ID_TE: case ID_NT:
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
case ID_LA: case ID_CA: case ID_WO:
Added support for animation of line style parameters. Most stylization parameters in line style datablocks are now animatable by means of keyframes. Right click on a line style parameter, and you will see a list of keyframe-related commands in the context menu. Concerning the implementation, RNA path resolution has been extended to properly address color ramps in line style color modifiers. File I/O has been also improved to load/save the animation data associated with line style datablocks. Known issue: Freestyle-related options in render layers are not animatable at the moment, because of general inability (or maybe a bug) that keyframes cannot be inserted with respect to render layer options.
2010-09-18 00:31:22 +00:00
case ID_LS:
Rename probe to light-probe Probe is a real general term, the new name is used often in docs online.
2017-06-12 20:59:54 +10:00
case ID_LP:
3D Audio GSoC: Adds new speaker object type. Notes: * Needs some nice icons * Quickily review by Joshua Leung (5 mins) * Properties UI updated (with help of Thomans Dinges) * Speakers have their own theme color * No real audio functionality yet. * Minor bug regarding lamps/lattices fixed in interface_templates.c I personality tested: * Creation, Deletion, Duplication * Saving, Loading * Library linking (incl. make local) * Tracking * Dope Sheet, Outliner * Animation * Drawing (incl. Theme)
2011-08-01 11:44:20 +00:00
case ID_SPK:
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
case ID_SCE:
Camera tracking: animation datablock for MovieClip Added AnimData block to MovieClip datablock which allows to animate different properties in clip. Currently supports animation of stabilization influence only. -- svn merge -r44129:44130 ^/branches/soc-2011-tomato
2012-02-17 08:13:45 +00:00
case ID_MC:
mask mode for clip editor developed by Sergey Sharybin, Pete Larabell and myself. see: http://wiki.blender.org/index.php/User:Nazg-gul/MaskEditor note - mask editing tools need continued development, feather option is not working 100%
2012-06-04 16:42:58 +00:00
case ID_MSK:
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
case ID_GD:
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
case ID_CF:
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return true;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
/* no AnimData */
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
default:
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return false;
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
}
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
}
Cleanup/fix animsys 'id_type_can_have_animdata()'. This func now actually takes an ID type as argument, added new 'id_can_have_animdata()' to check whether a datablock may be animated or not.
2016-07-07 20:48:33 +02:00
bool id_can_have_animdata(const ID *id)
{
/* sanity check */
if (id == NULL)
return false;
return id_type_can_have_animdata(GS(id->name));
}
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Get AnimData from the given ID-block. In order for this to work, we assume that
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
* the AnimData pointer is stored immediately after the given ID-block in the struct,
* as per IdAdtTemplate.
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimData *BKE_animdata_from_id(ID *id)
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
{
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* only some ID-blocks have this info for now, so we cast the
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
* types that do to be of type IdAdtTemplate, and extract the
* AnimData that way
*/
Cleanup/fix animsys 'id_type_can_have_animdata()'. This func now actually takes an ID type as argument, added new 'id_can_have_animdata()' to check whether a datablock may be animated or not.
2016-07-07 20:48:33 +02:00
if (id_can_have_animdata(id)) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
IdAdtTemplate *iat = (IdAdtTemplate *)id;
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
return iat->adt;
}
else
return NULL;
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
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Add AnimData to the given ID-block. In order for this to work, we assume that
2.5 - AnimData fixes * Made AnimData blocks be stored as pointer instead of directly in the ID-datablock, so that fewer files will need to be recompiled everytime some animation settings change. * Tried to fix some of the compiler errors that pop up in Yafray code. If this commit doesn't fix it, just disable Yafray code for now (WITH_BF_YAFRAY=0 for scons)...
2009-01-17 05:36:58 +00:00
* the AnimData pointer is stored immediately after the given ID-block in the struct,
Cleanup: trailing whitespace (comment blocks) Strip unindented comment blocks - mainly headers to avoid conflicts.
2018-06-01 18:19:39 +02:00
* as per IdAdtTemplate. Also note that
2.5 - AnimData fixes * Made AnimData blocks be stored as pointer instead of directly in the ID-datablock, so that fewer files will need to be recompiled everytime some animation settings change. * Tried to fix some of the compiler errors that pop up in Yafray code. If this commit doesn't fix it, just disable Yafray code for now (WITH_BF_YAFRAY=0 for scons)...
2009-01-17 05:36:58 +00:00
*/
Cleanup: use BKE_animdata_* prefix
2015-04-04 15:13:56 +11:00
AnimData *BKE_animdata_add_id(ID *id)
2.5 - AnimData fixes * Made AnimData blocks be stored as pointer instead of directly in the ID-datablock, so that fewer files will need to be recompiled everytime some animation settings change. * Tried to fix some of the compiler errors that pop up in Yafray code. If this commit doesn't fix it, just disable Yafray code for now (WITH_BF_YAFRAY=0 for scons)...
2009-01-17 05:36:58 +00:00
{
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Only some ID-blocks have this info for now, so we cast the
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
* types that do to be of type IdAdtTemplate, and add the AnimData
* to it using the template
*/
Cleanup/fix animsys 'id_type_can_have_animdata()'. This func now actually takes an ID type as argument, added new 'id_can_have_animdata()' to check whether a datablock may be animated or not.
2016-07-07 20:48:33 +02:00
if (id_can_have_animdata(id)) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
IdAdtTemplate *iat = (IdAdtTemplate *)id;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - Basic version patching support This is work-in-progress patching support for converting animation saved in old system to work in the new one. * Only IPOs/Actions directly attached to Objects + Shapekeys are converted for now. More types will follow... * This is currently done as a step outside of do_versions() due to problems with various pointers not having been resolved yet, but which are necessary for correct resolution of issues such as drivers... However, the current code does illustrate how the data should be converted to give best results/compat between the two systems. * Still need to get the converted data working with depsgraph correctly. Currently, some of my testfiles work, but the BBB files still don't.
2009-01-22 10:53:22 +00:00
/* check if there's already AnimData, in which case, don't add */
Animato - NLA + Realtime Animating Goodies * When doing realtime recording of animation (i.e. transforming objects + bones while animation playback is running, and auto-keying is enabled), animation will be added to a new NLA Track+Strip combo everytime a single 'loop' of the frame range has finished. This will allow 'passes' over the animation to be less destructive. * Made the evaluation of the active action (when NLA data is present), be handled as part of the normal NLA system evaluation code (as if it were just another strip in a track at the end). The immediate benefit is that there are now some settings (available in the "Animation Data" panel in the NLA Editor with a strip selected) which allow for the way the active action is combined with the NLA stack results. For instance, the way that the action extrapolates is used in the recording tweaks above.
2009-07-31 07:43:47 +00:00
if (iat->adt == NULL) {
AnimData *adt;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - NLA + Realtime Animating Goodies * When doing realtime recording of animation (i.e. transforming objects + bones while animation playback is running, and auto-keying is enabled), animation will be added to a new NLA Track+Strip combo everytime a single 'loop' of the frame range has finished. This will allow 'passes' over the animation to be less destructive. * Made the evaluation of the active action (when NLA data is present), be handled as part of the normal NLA system evaluation code (as if it were just another strip in a track at the end). The immediate benefit is that there are now some settings (available in the "Animation Data" panel in the NLA Editor with a strip selected) which allow for the way the active action is combined with the NLA stack results. For instance, the way that the action extrapolates is used in the recording tweaks above.
2009-07-31 07:43:47 +00:00
/* add animdata */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
adt = iat->adt = MEM_callocN(sizeof(AnimData), "AnimData");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - NLA + Realtime Animating Goodies * When doing realtime recording of animation (i.e. transforming objects + bones while animation playback is running, and auto-keying is enabled), animation will be added to a new NLA Track+Strip combo everytime a single 'loop' of the frame range has finished. This will allow 'passes' over the animation to be less destructive. * Made the evaluation of the active action (when NLA data is present), be handled as part of the normal NLA system evaluation code (as if it were just another strip in a track at the end). The immediate benefit is that there are now some settings (available in the "Animation Data" panel in the NLA Editor with a strip selected) which allow for the way the active action is combined with the NLA stack results. For instance, the way that the action extrapolates is used in the recording tweaks above.
2009-07-31 07:43:47 +00:00
/* set default settings */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
adt->act_influence = 1.0f;
Animato - NLA + Realtime Animating Goodies * When doing realtime recording of animation (i.e. transforming objects + bones while animation playback is running, and auto-keying is enabled), animation will be added to a new NLA Track+Strip combo everytime a single 'loop' of the frame range has finished. This will allow 'passes' over the animation to be less destructive. * Made the evaluation of the active action (when NLA data is present), be handled as part of the normal NLA system evaluation code (as if it were just another strip in a track at the end). The immediate benefit is that there are now some settings (available in the "Animation Data" panel in the NLA Editor with a strip selected) which allow for the way the active action is combined with the NLA stack results. For instance, the way that the action extrapolates is used in the recording tweaks above.
2009-07-31 07:43:47 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
return iat->adt;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
else
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
return NULL;
}
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
/* Action Setter --------------------------------------- */
/* Called when user tries to change the active action of an AnimData block (via RNA, Outliner, etc.) */
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
bool BKE_animdata_set_action(ReportList *reports, ID *id, bAction *act)
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
{
AnimData *adt = BKE_animdata_from_id(id);
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
bool ok = false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
/* animdata validity check */
if (adt == NULL) {
BKE_report(reports, RPT_WARNING, "No AnimData to set action on");
return ok;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* active action is only editable when it is not a tweaking strip
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
* see rna_AnimData_action_editable() in rna_animation.c
*/
if ((adt->flag & ADT_NLA_EDIT_ON) || (adt->actstrip) || (adt->tmpact)) {
/* cannot remove, otherwise things turn to custard */
BKE_report(reports, RPT_ERROR, "Cannot change action, as it is still being edited in NLA");
return ok;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
/* manage usercount for current action */
if (adt->action)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
id_us_min((ID *)adt->action);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
/* assume that AnimData's action can in fact be edited... */
if (act) {
/* action must have same type as owner */
if (ELEM(act->idroot, 0, GS(id->name))) {
/* can set */
adt->action = act;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
id_us_plus((ID *)adt->action);
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
ok = true;
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
}
else {
/* cannot set */
BKE_reportf(reports, RPT_ERROR,
A final bunch of UI messages fixes and tweaks, and some BKE_report()<->BKE_reportf() fixes.
2012-10-21 14:02:30 +00:00
"Could not set action '%s' onto ID '%s', as it does not have suitably rooted paths "
"for this purpose", act->id.name + 2, id->name);
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
/* ok = false; */
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
}
}
else {
/* just clearing the action... */
adt->action = NULL;
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
ok = true;
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Outliner RMB Menu - AnimData mangement * When clicking on "Animation" items in the Outliner, there's now a menu containing from which you can change the action used, and refresh/delete all drivers. * Moved action-setting logic for AnimData actions to a single utility function in anim_sys, since this was starting to be done in too many places already. * Fixed Outliner refresh bug after changing the active action
2011-07-07 03:35:48 +00:00
return ok;
}
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* Freeing -------------------------------------------- */
/* Free AnimData used by the nominated ID-block, and clear ID-block's AnimData pointer */
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling). This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock was pretty much impossible, except for a few special cases. Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite a few ID usages were missed or wrongly handled that way). One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling by using library_query utils to allow generic handling of those, which is now the case (now, generic ID links handling is only "knwon" from readfile.c and library_query.c). This commit also adds backends to allow live replacement and deletion of datablocks in Blender (so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one, or NULL one in case of unlinking). This will allow nice new features, like ability to easily reload or relocate libraries, real immediate deletion of datablocks in blender, replacement of one datablock by another, etc. Some of those are for next commits. A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core. Though it was tested rather deeply, being totally impossible to check all possible ID usage cases, it's likely there are some remaining issues and bugs in new code... Please report them! ;) Review task: D2027 (https://developer.blender.org/D2027). Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
void BKE_animdata_free(ID *id, const bool do_id_user)
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
{
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Only some ID-blocks have this info for now, so we cast the
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
* types that do to be of type IdAdtTemplate
2.5 - AnimData fixes * Made AnimData blocks be stored as pointer instead of directly in the ID-datablock, so that fewer files will need to be recompiled everytime some animation settings change. * Tried to fix some of the compiler errors that pop up in Yafray code. If this commit doesn't fix it, just disable Yafray code for now (WITH_BF_YAFRAY=0 for scons)...
2009-01-17 05:36:58 +00:00
*/
Cleanup/fix animsys 'id_type_can_have_animdata()'. This func now actually takes an ID type as argument, added new 'id_can_have_animdata()' to check whether a datablock may be animated or not.
2016-07-07 20:48:33 +02:00
if (id_can_have_animdata(id)) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
IdAdtTemplate *iat = (IdAdtTemplate *)id;
AnimData *adt = iat->adt;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* check if there's any AnimData to start with */
if (adt) {
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling). This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock was pretty much impossible, except for a few special cases. Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite a few ID usages were missed or wrongly handled that way). One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling by using library_query utils to allow generic handling of those, which is now the case (now, generic ID links handling is only "knwon" from readfile.c and library_query.c). This commit also adds backends to allow live replacement and deletion of datablocks in Blender (so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one, or NULL one in case of unlinking). This will allow nice new features, like ability to easily reload or relocate libraries, real immediate deletion of datablocks in blender, replacement of one datablock by another, etc. Some of those are for next commits. A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core. Though it was tested rather deeply, being totally impossible to check all possible ID usage cases, it's likely there are some remaining issues and bugs in new code... Please report them! ;) Review task: D2027 (https://developer.blender.org/D2027). Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
if (do_id_user) {
/* unlink action (don't free, as it's in its own list) */
if (adt->action)
id_us_min(&adt->action->id);
/* same goes for the temporarily displaced action */
if (adt->tmpact)
id_us_min(&adt->tmpact->id);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Part 1 of NLA-Data Management API In this commit: * Added code for freeing NLA data now stored in AnimData * Started writing some utilities for adding NLA data, especially the 'push-down' concept for Actions * Cleanups of existing code - removal of obsolete NLA code from various places Next commits/parts: * File IO code for new-style NLA data * Version patching for old data to new data
2009-05-22 01:16:26 +00:00
/* free nla data */
Fix unneeded/unwanted user counter when freeing CoW NLA
2018-10-29 11:13:19 +01:00
BKE_nla_tracks_free(&adt->nla_tracks, do_id_user);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* free drivers - stored as a list of F-Curves */
free_fcurves(&adt->drivers);
Depsgraph: optimization of driver evaluation with many drivers.
2018-05-31 06:04:25 +02:00
/* free driver array cache */
MEM_SAFE_FREE(adt->driver_array);
Merge branch 'master' into blender2.8
2018-06-17 17:10:19 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* free overrides */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO... */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* free animdata now */
MEM_freeN(adt);
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
iat->adt = NULL;
2.5 - AnimData fixes * Made AnimData blocks be stored as pointer instead of directly in the ID-datablock, so that fewer files will need to be recompiled everytime some animation settings change. * Tried to fix some of the compiler errors that pop up in Yafray code. If this commit doesn't fix it, just disable Yafray code for now (WITH_BF_YAFRAY=0 for scons)...
2009-01-17 05:36:58 +00:00
}
}
}
Code cleanup - Fixed incorrect section heading - Missed one place where short was still used when the specific enum type would be more appropriate
2014-07-06 19:32:50 +12:00
/* Copying -------------------------------------------- */
2.5 - AnimData fixes * Made AnimData blocks be stored as pointer instead of directly in the ID-datablock, so that fewer files will need to be recompiled everytime some animation settings change. * Tried to fix some of the compiler errors that pop up in Yafray code. If this commit doesn't fix it, just disable Yafray code for now (WITH_BF_YAFRAY=0 for scons)...
2009-01-17 05:36:58 +00:00
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
/**
* Make a copy of the given AnimData - to be used when copying datablocks.
Merge branch 'master' into blender2.8
2018-12-12 12:55:20 +11:00
* \param flag: Control ID pointers management, see LIB_ID_CREATE_.../LIB_ID_COPY_... flags in BKE_library.h
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
* \return The copied animdata.
*/
AnimData *BKE_animdata_copy(Main *bmain, AnimData *adt, const int flag)
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
{
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
AnimData *dadt;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
const bool do_action = (flag & LIB_ID_COPY_ACTIONS) != 0 && (flag & LIB_ID_CREATE_NO_MAIN) == 0;
const bool do_id_user = (flag & LIB_ID_CREATE_NO_USER_REFCOUNT) == 0;
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* sanity check before duplicating struct */
if (adt == NULL)
return NULL;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
dadt = MEM_dupallocN(adt);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* make a copy of action - at worst, user has to delete copies... */
Adding support for adding copies of existing drivers to other animdata blocks via PyAPI/RNA For example: ob = bpy.context.active_object # assumes default cube has some drivers added already before running script dst = bpy.data.objects["Camera"] adt = dst.animation_data_create() for driver in ob.animation_data.drivers: new_driver = adt.drivers.from_existing(driver)
2011-04-26 13:49:40 +00:00
if (do_action) {
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
BLI_assert(bmain != NULL);
Cleanup: replace BKE_id_copy_ex by BKE_id_copy where possible. That way it is obvious when we are using default ID copy behaviour, and when we are using advanced/specialized ones.
2019-02-04 20:38:01 +01:00
BKE_id_copy(bmain, (ID *)dadt->action, (ID **)&dadt->action);
BKE_id_copy(bmain, (ID *)dadt->tmpact, (ID **)&dadt->tmpact);
bugfix [#24403] Object.copy() duplicates armature action now duplicating ID data wont duplicate actions by default and the user preference is used with duplicate operators.
2010-11-09 09:53:17 +00:00
}
Animation: Don't user-copunter copy-on-written action block
2018-04-30 16:27:24 +02:00
else if (do_id_user) {
bugfix [#24403] Object.copy() duplicates armature action now duplicating ID data wont duplicate actions by default and the user preference is used with duplicate operators.
2010-11-09 09:53:17 +00:00
id_us_plus((ID *)dadt->action);
id_us_plus((ID *)dadt->tmpact);
}
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* duplicate NLA data */
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
BKE_nla_tracks_copy(bmain, &dadt->nla_tracks, &adt->nla_tracks, flag);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* duplicate drivers (F-Curves) */
copy_fcurves(&dadt->drivers, &adt->drivers);
Depsgraph: optimization of driver evaluation with many drivers.
2018-05-31 06:04:25 +02:00
dadt->driver_array = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* don't copy overrides */
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
BLI_listbase_clear(&dadt->overrides);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* return */
return dadt;
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
}
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
/**
Merge branch 'master' into blender2.8
2018-12-12 12:55:20 +11:00
* \param flag: Control ID pointers management, see LIB_ID_CREATE_.../LIB_ID_COPY_... flags in BKE_library.h
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
* \return true is succesfully copied.
*/
bool BKE_animdata_copy_id(Main *bmain, ID *id_to, ID *id_from, const int flag)
Make linked animdata working again, copies NLA too, as well as ObData animdata where types match
2010-01-10 20:23:59 +00:00
{
AnimData *adt;
Adding support for adding copies of existing drivers to other animdata blocks via PyAPI/RNA For example: ob = bpy.context.active_object # assumes default cube has some drivers added already before running script dst = bpy.data.objects["Camera"] adt = dst.animation_data_create() for driver in ob.animation_data.drivers: new_driver = adt.drivers.from_existing(driver)
2011-04-26 13:49:40 +00:00
if ((id_to && id_from) && (GS(id_to->name) != GS(id_from->name)))
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return false;
Make linked animdata working again, copies NLA too, as well as ObData animdata where types match
2010-01-10 20:23:59 +00:00
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
BKE_animdata_free(id_to, (flag & LIB_ID_CREATE_NO_USER_REFCOUNT) == 0);
Make linked animdata working again, copies NLA too, as well as ObData animdata where types match
2010-01-10 20:23:59 +00:00
adt = BKE_animdata_from_id(id_from);
if (adt) {
IdAdtTemplate *iat = (IdAdtTemplate *)id_to;
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
iat->adt = BKE_animdata_copy(bmain, adt, flag);
Make linked animdata working again, copies NLA too, as well as ObData animdata where types match
2010-01-10 20:23:59 +00:00
}
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return true;
Make linked animdata working again, copies NLA too, as well as ObData animdata where types match
2010-01-10 20:23:59 +00:00
}
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
void BKE_animdata_copy_id_action(Main *bmain, ID *id, const bool set_newid)
bugfix [#24403] Object.copy() duplicates armature action now duplicating ID data wont duplicate actions by default and the user preference is used with duplicate operators.
2010-11-09 09:53:17 +00:00
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimData *adt = BKE_animdata_from_id(id);
Adding support for adding copies of existing drivers to other animdata blocks via PyAPI/RNA For example: ob = bpy.context.active_object # assumes default cube has some drivers added already before running script dst = bpy.data.objects["Camera"] adt = dst.animation_data_create() for driver in ob.animation_data.drivers: new_driver = adt.drivers.from_existing(driver)
2011-04-26 13:49:40 +00:00
if (adt) {
if (adt->action) {
id_us_min((ID *)adt->action);
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
adt->action = set_newid ? ID_NEW_SET(adt->action, BKE_action_copy(bmain, adt->action)) :
BKE_action_copy(bmain, adt->action);
bugfix [#24403] Object.copy() duplicates armature action now duplicating ID data wont duplicate actions by default and the user preference is used with duplicate operators.
2010-11-09 09:53:17 +00:00
}
Adding support for adding copies of existing drivers to other animdata blocks via PyAPI/RNA For example: ob = bpy.context.active_object # assumes default cube has some drivers added already before running script dst = bpy.data.objects["Camera"] adt = dst.animation_data_create() for driver in ob.animation_data.drivers: new_driver = adt.drivers.from_existing(driver)
2011-04-26 13:49:40 +00:00
if (adt->tmpact) {
id_us_min((ID *)adt->tmpact);
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
adt->tmpact = set_newid ? ID_NEW_SET(adt->tmpact, BKE_action_copy(bmain, adt->tmpact)) :
BKE_action_copy(bmain, adt->tmpact);
bugfix [#24403] Object.copy() duplicates armature action now duplicating ID data wont duplicate actions by default and the user preference is used with duplicate operators.
2010-11-09 09:53:17 +00:00
}
}
}
Make linked animdata working again, copies NLA too, as well as ObData animdata where types match
2010-01-10 20:23:59 +00:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
/* Merge copies of the data from the src AnimData into the destination AnimData */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
void BKE_animdata_merge_copy(
Main *bmain, ID *dst_id, ID *src_id,
eAnimData_MergeCopy_Modes action_mode, bool fix_drivers)
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
{
AnimData *src = BKE_animdata_from_id(src_id);
AnimData *dst = BKE_animdata_from_id(dst_id);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
/* sanity checks */
if (ELEM(NULL, dst, src))
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
// TODO: we must unset all "tweakmode" flags
if ((src->flag & ADT_NLA_EDIT_ON) || (dst->flag & ADT_NLA_EDIT_ON)) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "Merging AnimData blocks while editing NLA is dangerous as it may cause data corruption");
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
return;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
/* handle actions... */
if (action_mode == ADT_MERGECOPY_SRC_COPY) {
/* make a copy of the actions */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
dst->action = BKE_action_copy(bmain, src->action);
dst->tmpact = BKE_action_copy(bmain, src->tmpact);
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
}
else if (action_mode == ADT_MERGECOPY_SRC_REF) {
/* make a reference to it */
dst->action = src->action;
id_us_plus((ID *)dst->action);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
dst->tmpact = src->tmpact;
id_us_plus((ID *)dst->tmpact);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
/* duplicate NLA data */
if (src->nla_tracks.first) {
ListBase tracks = {NULL, NULL};
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix dpesgraph wrongly refcounting NLA strip actions when duplicating IDs. NLA strips are users of their action, so we need to pass along ID management flags. This commit also cleans up a bit things by passing along ID_CREATE/COPY flags instead of dummy booleans...
2018-11-07 13:55:29 +01:00
BKE_nla_tracks_copy(bmain, &tracks, &src->nla_tracks, 0);
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
BLI_movelisttolist(&dst->nla_tracks, &tracks);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
/* duplicate drivers (F-Curves) */
if (src->drivers.first) {
ListBase drivers = {NULL, NULL};
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
copy_fcurves(&drivers, &src->drivers);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
/* Fix up all driver targets using the old target id
* - This assumes that the src ID is being merged into the dst ID
*/
if (fix_drivers) {
FCurve *fcu;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
for (fcu = drivers.first; fcu; fcu = fcu->next) {
ChannelDriver *driver = fcu->driver;
DriverVar *dvar;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
for (dvar = driver->variables.first; dvar; dvar = dvar->next) {
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_USED_LOOPER_BEGIN(dvar)
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
{
if (dtar->id == src_id) {
dtar->id = dst_id;
}
}
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_LOOPER_END;
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
}
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures loses drivers Currently, when joining two armatures, the drivers of the armatures being merged in are lost. This commit introduces a new AnimData API function for merging animation data into another AnimData block. NOTE: * For now, this only copies the drivers over. As a result, manual effort will still be needed to go through and fix the drivers. I am working on automating that process, but it's more important that the drivers don't have to be created from scratch for now (since this is needed for the Goosberry rigging work).
2015-01-22 02:08:29 +13:00
BLI_movelisttolist(&dst->drivers, &drivers);
}
}
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* Sub-ID Regrouping ------------------------------------------- */
Cleanup: Use doxy for more structured comments
2014-05-29 21:16:04 +10:00
/**
* Helper heuristic for determining if a path is compatible with the basepath
*
Cleanup: use colon separator after parameter Helps separate variable names from descriptive text. Was already used in some parts of the code, double space and dashes were used elsewhere.
2018-12-12 12:50:58 +11:00
* \param path: Full RNA-path from some data (usually an F-Curve) to compare
* \param basepath: Shorter path fragment to look for
Cleanup: Use doxy for more structured comments
2014-05-29 21:16:04 +10:00
* \return Whether there is a match
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
*/
Replace inefficient use of strstr with STRPREFIX macro
2014-05-10 09:27:44 +10:00
static bool animpath_matches_basepath(const char path[], const char basepath[])
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
{
/* we need start of path to be basepath */
Replace inefficient use of strstr with STRPREFIX macro
2014-05-10 09:27:44 +10:00
return (path && basepath) && STRPREFIX(path, basepath);
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Move F-Curves in src action to dst action, setting up all the necessary groups
Cleanup: trailing whitespace (comment blocks) Strip unindented comment blocks - mainly headers to avoid conflicts.
2018-06-01 18:19:39 +02:00
* for this to happen, but only if the F-Curves being moved have the appropriate
* "base path".
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - This is used when data moves from one datablock to another, causing the
* F-Curves to need to be moved over too
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void action_move_fcurves_by_basepath(bAction *srcAct, bAction *dstAct, const char basepath[])
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
FCurve *fcu, *fcn = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* sanity checks */
Defines: replace ELEM3-16 with ELEM(...), that can take varargs
2014-07-20 01:30:29 +10:00
if (ELEM(NULL, srcAct, dstAct, basepath)) {
move debug flag into its own global var (G.debug), split up debug options. --debug --debug-ffmpeg --debug-python --debug-events --debug-wm This makes debug output easier to read - event debug prints would flood output too much before. For convenience: --debug-all turns all debug flags on (works as --debug did before). also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
2012-03-31 00:59:17 +00:00
if (G.debug & G_DEBUG) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "srcAct: %p, dstAct: %p, basepath: %p has insufficient info to work with",
Cleanup: style
2019-02-06 09:14:11 +11:00
(void *)srcAct, (void *)dstAct, (void *)basepath);
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
}
return;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* clear 'temp' flags on all groups in src, as we'll be needing them later
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
* to identify groups that we've managed to empty out here
*/
action_groups_clear_tempflags(srcAct);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* iterate over all src F-Curves, moving over the ones that need to be moved */
for (fcu = srcAct->curves.first; fcu; fcu = fcn) {
/* store next pointer in case we move stuff */
fcn = fcu->next;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* should F-Curve be moved over?
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - we only need the start of the path to match basepath
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
*/
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
if (animpath_matches_basepath(fcu->rna_path, basepath)) {
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
bActionGroup *agrp = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* if grouped... */
if (fcu->grp) {
/* make sure there will be a matching group on the other side for the migrants */
code cleanup: naming - pose/armature/image also use ..._find_name(..., name) rather then ..._find_named(..., name) --- both were used.
2012-05-05 16:03:57 +00:00
agrp = BKE_action_group_find_name(dstAct, fcu->grp->name);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
if (agrp == NULL) {
/* add a new one with a similar name (usually will be the same though) */
agrp = action_groups_add_new(dstAct, fcu->grp->name);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* old groups should be tagged with 'temp' flags so they can be removed later
* if we remove everything from them
*/
fcu->grp->flag |= AGRP_TEMP;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* perform the migration now */
action_groups_remove_channel(srcAct, fcu);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
if (agrp)
action_groups_add_channel(dstAct, agrp, fcu);
else
BLI_addtail(&dstAct->curves, fcu);
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* cleanup groups (if present) */
if (srcAct->groups.first) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
bActionGroup *agrp, *grp = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
for (agrp = srcAct->groups.first; agrp; agrp = grp) {
grp = agrp->next;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* only tagged groups need to be considered - clearing these tags or removing them */
if (agrp->flag & AGRP_TEMP) {
/* if group is empty and tagged, then we can remove as this operation
* moved out all the channels that were formerly here
*/
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
if (BLI_listbase_is_empty(&agrp->channels))
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
BLI_freelinkN(&srcAct->groups, agrp);
else
agrp->flag &= ~AGRP_TEMP;
}
}
}
}
/* Transfer the animation data from srcID to dstID where the srcID
* animation data is based off "basepath", creating new AnimData and
* associated data as necessary
*/
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
void BKE_animdata_separate_by_basepath(
Main *bmain, ID *srcID, ID *dstID, ListBase *basepaths)
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimData *srcAdt = NULL, *dstAdt = NULL;
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
LinkData *ld;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* sanity checks */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, srcID, dstID)) {
move debug flag into its own global var (G.debug), split up debug options. --debug --debug-ffmpeg --debug-python --debug-events --debug-wm This makes debug output easier to read - event debug prints would flood output too much before. For convenience: --debug-all turns all debug flags on (works as --debug did before). also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
2012-03-31 00:59:17 +00:00
if (G.debug & G_DEBUG)
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "no source or destination ID to separate AnimData with");
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
return;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* get animdata from src, and create for destination (if needed) */
srcAdt = BKE_animdata_from_id(srcID);
Cleanup: use BKE_animdata_* prefix
2015-04-04 15:13:56 +11:00
dstAdt = BKE_animdata_add_id(dstID);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, srcAdt, dstAdt)) {
move debug flag into its own global var (G.debug), split up debug options. --debug --debug-ffmpeg --debug-python --debug-events --debug-wm This makes debug output easier to read - event debug prints would flood output too much before. For convenience: --debug-all turns all debug flags on (works as --debug did before). also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
2012-03-31 00:59:17 +00:00
if (G.debug & G_DEBUG)
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "no AnimData for this pair of ID's");
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
return;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* active action */
if (srcAdt->action) {
/* set up an action if necessary, and name it in a similar way so that it can be easily found again */
if (dstAdt->action == NULL) {
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
dstAdt->action = BKE_action_add(bmain, srcAdt->action->id.name + 2);
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
}
else if (dstAdt->action == srcAdt->action) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_WARN(&LOG, "Argh! Source and Destination share animation! "
Cleanup: style
2019-02-06 09:14:11 +11:00
"('%s' and '%s' both use '%s') Making new empty action",
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
srcID->name, dstID->name, srcAdt->action->id.name);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: review this... */
Various pedantic fixes to satisfy compilers.
2010-12-30 05:41:17 +00:00
id_us_min(&dstAdt->action->id);
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
dstAdt->action = BKE_action_add(bmain, dstAdt->action->id.name + 2);
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* loop over base paths, trying to fix for each one... */
for (ld = basepaths->first; ld; ld = ld->next) {
const char *basepath = (const char *)ld->data;
action_move_fcurves_by_basepath(srcAdt->action, dstAdt->action, basepath);
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* drivers */
if (srcAdt->drivers.first) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
FCurve *fcu, *fcn = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* check each driver against all the base paths to see if any should go */
for (fcu = srcAdt->drivers.first; fcu; fcu = fcn) {
fcn = fcu->next;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* try each basepath in turn, but stop on the first one which works */
for (ld = basepaths->first; ld; ld = ld->next) {
const char *basepath = (const char *)ld->data;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
if (animpath_matches_basepath(fcu->rna_path, basepath)) {
/* just need to change lists */
BLI_remlink(&srcAdt->drivers, fcu);
BLI_addtail(&dstAdt->drivers, fcu);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: add depsgraph flushing calls? */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#24163] Unable to animate INSIDE a group node in the compositor This commit fixes the original bug reported here by adding some methods to move the relevant F-Curves (and drivers) over to the new Node-Tree's (i.e. group-node) AnimData. Animated nodes which subsequently get grouped will still be able to animate as a result of this commit. TODO's: - Ungrouping now will not yet merge the animation back (or at least copy it) - Buttons for nodes freshly grouped do not correctly show animated status indicators for some reason, yet normal animation does
2010-12-29 11:51:53 +00:00
/* can stop now, as moved already */
break;
}
}
}
}
}
2.5: Object module * Split object_edit.c into multiple files: object_add.c, object_edit.c, object_hook.c, object_relations.c, object_select.c, object_transform.c. * Rename files to have consistent object_ and mball_ prefix: object_shapekey.c, object_lattice.c, object_vgroup.c, mball_edit.c. * Added operators: * vertex group menu and set active * apply location, rotation, scale, visual transform (location is new) * make local * make vertex parent * move to layer * convert to curve/mesh (not finished yet) * Many small fixes for marked issues, but still much code to be cleaned up here...
2009-09-09 11:52:56 +00:00
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
/**
* Temporary wrapper for driver operators for buttons to make it easier to create
* such drivers by rerouting all paths through the active object instead so that
* they will get picked up by the dependency system.
*
Cleanup: use colon separator after parameter Helps separate variable names from descriptive text. Was already used in some parts of the code, double space and dashes were used elsewhere.
2018-12-12 12:50:58 +11:00
* \param C: Context pointer - for getting active data
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
* \param[in,out] ptr RNA pointer for property's datablock. May be modified as result of path remapping.
Cleanup: use colon separator after parameter Helps separate variable names from descriptive text. Was already used in some parts of the code, double space and dashes were used elsewhere.
2018-12-12 12:50:58 +11:00
* \param prop: RNA definition of property to add for
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
* \return MEM_alloc'd string representing the path to the property from the given #PointerRNA
*/
char *BKE_animdata_driver_path_hack(bContext *C, PointerRNA *ptr, PropertyRNA *prop, char *base_path)
{
ID *id = (ID *)ptr->id.data;
ScrArea *sa = CTX_wm_area(C);
/* get standard path which may be extended */
char *basepath = base_path ? base_path : RNA_path_from_ID_to_property(ptr, prop);
char *path = basepath; /* in case no remapping is needed */
/* Remapping will only be performed in the Properties Editor, as only this
* restricts the subspace of options to the 'active' data (a manageable state)
*/
/* TODO: watch out for pinned context? */
DNA: rename SpaceButs -> SpaceProperties
2019-02-16 10:44:15 +11:00
if ((sa) && (sa->spacetype == SPACE_PROPERTIES)) {
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
Object *ob = CTX_data_active_object(C);
if (ob && id) {
Remove Blender Internal and legacy viewport from Blender 2.8. Brecht authored this commit, but he gave me the honours to actually do it. Here it goes; Blender Internal. Bye bye, you did great! * Point density, voxel data, ocean, environment map textures were removed, as these only worked within BI rendering. Note that the ocean modifier and the Cycles point density shader node continue to work. * Dynamic paint using material shading was removed, as this only worked with BI. If we ever wanted to support this again probably it should go through the baking API. * GPU shader export through the Python API was removed. This only worked for the old BI GLSL shaders, which no longer exists. Doing something similar for Eevee would be significantly more complicated because it uses a lot of multiplass rendering and logic outside the shader, it's probably impractical. * Collada material import / export code is mostly gone, as it only worked for BI materials. We need to add Cycles / Eevee material support at some point. * The mesh noise operator was removed since it only worked with BI material texture slots. A displacement modifier can be used instead. * The delete texture paint slot operator was removed since it only worked for BI material texture slots. Could be added back with node support. * Not all legacy viewport features are supported in the new viewport, but their code was removed. If we need to bring anything back we can look at older git revisions. * There is some legacy viewport code that I could not remove yet, and some that I probably missed. * Shader node execution code was left mostly intact, even though it is not used anywhere now. We may eventually use this to replace the texture nodes with Cycles / Eevee shader nodes. * The Cycles Bake panel now includes settings for baking multires normal and displacement maps. The underlying code needs to be merged properly, and we plan to add back support for multires AO baking and add support to Cycles baking for features like vertex color, displacement, and other missing baking features. * This commit removes DNA and the Python API for BI material, lamp, world and scene settings. This breaks a lot of addons. * There is more DNA that can be removed or renamed, where Cycles or Eevee are reusing some old BI properties but the names are not really correct anymore. * Texture slots for materials, lamps and world were removed. They remain for brushes, particles and freestyle linestyles. * 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and other renderers use this to find all panels to show, minus a few panels that they have their own replacement for.
2018-04-19 17:34:44 +02:00
/* TODO: after material textures were removed, this function serves
* no purpose anymore, but could be used again so was not removed. */
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
/* fix RNA pointer, as we've now changed the ID root by changing the paths */
if (basepath != path) {
/* rebase provided pointer so that it starts from object... */
RNA_pointer_create(&ob->id, ptr->type, ptr->data, ptr);
}
}
}
/* the path should now have been corrected for use */
return path;
}
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
/* Path Validation -------------------------------------------- */
2.5: Object module * Split object_edit.c into multiple files: object_add.c, object_edit.c, object_hook.c, object_relations.c, object_select.c, object_transform.c. * Rename files to have consistent object_ and mball_ prefix: object_shapekey.c, object_lattice.c, object_vgroup.c, mball_edit.c. * Added operators: * vertex group menu and set active * apply location, rotation, scale, visual transform (location is new) * make local * make vertex parent * move to layer * convert to curve/mesh (not finished yet) * Many small fixes for marked issues, but still much code to be cleaned up here...
2009-09-09 11:52:56 +00:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* Check if a given RNA Path is valid, by tracing it from the given ID, and seeing if we can resolve it */
Bugfix [#34836] Crash when driver variable has path == 'data' Most of the places which relied on RNA_path_resolve() did so believing that if it returned true, that it had found a valid property, and that the returned pointer+property combination would be what the path referred to. However, it turns out that if the property at the end of the path turns out to be a "pointer" property (e.g. "data" for Object.data), this would automatically become the pointer part, while the prop part would be set to null. Hence, if a user accidentally (or otherwise) specifies a path for the single-property driver variable type like this, then Blender would crash. This commit introduces two convenience functions - RNA_path_resolve_property() and RNA_path_resolve_property_full() - which mirror/wrap the existing RNA_path_resolve() functions. The only difference though is that these include a check to ensure that what was found from resolving the path was in fact a property (they only return true iff this is the case), and make it explicitly clear in the name that this is what they will do so that there's no further confusion. It is possible to do without these wrapper functions by doing these checks inline, but the few cases that had been patched already were pretty hideous looking specimens. Using these just make it clearer and simpler for all. I've also beefed up the docs on these a bit, and changed these to using bools.
2013-04-22 13:22:07 +00:00
static bool check_rna_path_is_valid(ID *owner_id, const char *path)
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
{
PointerRNA id_ptr, ptr;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
PropertyRNA *prop = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* make initial RNA pointer to start resolving from */
RNA_id_pointer_create(owner_id, &id_ptr);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* try to resolve */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
return RNA_path_resolve_property(&id_ptr, path, &ptr, &prop);
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Check if some given RNA Path needs fixing - free the given path and set a new one as appropriate
Fixes for Path-Renaming Fix: * Now the old/new names get tagged with [" "] before the search and replace operation, which should alleviate problems with searching for 'bone' and ending up with all instances of 'boney' 'boney.r' etc. also getting renamed. * Cleaned up some compiler warnings, and removed an unused function from an earlier attempt at this work.
2009-10-20 04:07:57 +00:00
* NOTE: we assume that oldName and newName have [" "] padding around them
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
*/
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
static char *rna_path_rename_fix(ID *owner_id, const char *prefix, const char *oldName, const char *newName, char *oldpath, bool verify_paths)
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
char *prefixPtr = strstr(oldpath, prefix);
char *oldNamePtr = strstr(oldpath, oldName);
int prefixLen = strlen(prefix);
int oldNameLen = strlen(oldName);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* only start fixing the path if the prefix and oldName feature in the path,
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
* and prefix occurs immediately before oldName
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ( (prefixPtr && oldNamePtr) && (prefixPtr + prefixLen == oldNamePtr) ) {
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* if we haven't aren't able to resolve the path now, try again after fixing it */
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
if (!verify_paths || check_rna_path_is_valid(owner_id, oldpath) == 0) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
DynStr *ds = BLI_dynstr_new();
Code cleanup: use 'const' for arrays (blenkernel)
2014-04-27 00:20:13 +10:00
const char *postfixPtr = oldNamePtr + oldNameLen;
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
char *newPath = NULL;
Cleanup: avoid temp string edit
2016-06-04 10:51:34 +10:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* add the part of the string that goes up to the start of the prefix */
if (prefixPtr > oldpath) {
Cleanup: avoid temp string edit
2016-06-04 10:51:34 +10:00
BLI_dynstr_nappend(ds, oldpath, prefixPtr - oldpath);
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* add the prefix */
BLI_dynstr_append(ds, prefix);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* add the new name (complete with brackets) */
BLI_dynstr_append(ds, newName);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* add the postfix */
BLI_dynstr_append(ds, postfixPtr);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* create new path, and cleanup old data */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
newPath = BLI_dynstr_get_cstring(ds);
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
BLI_dynstr_free(ds);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* check if the new path will solve our problems */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: will need to check whether this step really helps in practice */
Fix [#21165] Moved textures don't move the animation curves
2010-03-16 07:44:57 +00:00
if (!verify_paths || check_rna_path_is_valid(owner_id, newPath)) {
Two fixes: * RNA Path fixing when renaming data now checks if a path in question cannot be resolved before trying to fix it. This should reduce the number of misindentified cases I hope. * Silenced compiler warnings for EdgeSlide stuff that mingw was making about unused variables.
2009-10-22 03:12:44 +00:00
/* free the old path, and return the new one, since we've solved the issues */
MEM_freeN(oldpath);
return newPath;
}
else {
/* still couldn't resolve the path... so, might as well just leave it alone */
MEM_freeN(newPath);
}
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* the old path doesn't need to be changed */
return oldpath;
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
}
/* Check RNA-Paths for a list of F-Curves */
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
static bool fcurves_path_rename_fix(ID *owner_id, const char *prefix, const char *oldName, const char *newName,
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
const char *oldKey, const char *newKey, ListBase *curves, bool verify_paths)
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
{
FCurve *fcu;
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
bool is_changed = false;
/* We need to check every curve. */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (fcu = curves->first; fcu; fcu = fcu->next) {
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
if (fcu->rna_path == NULL) {
continue;
}
const char *old_path = fcu->rna_path;
/* Firstly, handle the F-Curve's own path. */
fcu->rna_path = rna_path_rename_fix(owner_id, prefix, oldKey, newKey, fcu->rna_path, verify_paths);
/* if path changed and the F-Curve is grouped, check if its group also needs renaming
* (i.e. F-Curve is first of a bone's F-Curves; hence renaming this should also trigger rename) */
if (fcu->rna_path != old_path) {
bActionGroup *agrp = fcu->grp;
is_changed = true;
if ((agrp != NULL) && STREQ(oldName, agrp->name)) {
BLI_strncpy(agrp->name, newName, sizeof(agrp->name));
Bugfix [#32249] Groups in Dopesheet and Action editor don't get updated after bone renaming * Renaming F-Curves now checks if the corresponding F-Curve's group can also be renamed accordingly. * Changed the RNA updates for bone renaming so that they properly update the channel lists
2012-08-30 15:06:13 +00:00
}
}
Drivers Bugfix: Renaming bones now correctly fixes drivers referencing those bones. This includes driver paths and driver variables.
2010-05-17 04:22:41 +00:00
}
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
return is_changed;
Drivers Bugfix: Renaming bones now correctly fixes drivers referencing those bones. This includes driver paths and driver variables.
2010-05-17 04:22:41 +00:00
}
/* Check RNA-Paths for a list of Drivers */
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
static bool drivers_path_rename_fix(ID *owner_id, ID *ref_id, const char *prefix, const char *oldName, const char *newName,
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
const char *oldKey, const char *newKey, ListBase *curves, bool verify_paths)
Drivers Bugfix: Renaming bones now correctly fixes drivers referencing those bones. This includes driver paths and driver variables.
2010-05-17 04:22:41 +00:00
{
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
bool is_changed = false;
Drivers Bugfix: Renaming bones now correctly fixes drivers referencing those bones. This includes driver paths and driver variables.
2010-05-17 04:22:41 +00:00
FCurve *fcu;
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
/* We need to check every curve - drivers are F-Curves too. */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (fcu = curves->first; fcu; fcu = fcu->next) {
Drivers Bugfix: Renaming bones now correctly fixes drivers referencing those bones. This includes driver paths and driver variables.
2010-05-17 04:22:41 +00:00
/* firstly, handle the F-Curve's own path */
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
if (fcu->rna_path != NULL) {
const char *old_rna_path = fcu->rna_path;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
fcu->rna_path = rna_path_rename_fix(owner_id, prefix, oldKey, newKey, fcu->rna_path, verify_paths);
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
is_changed |= (fcu->rna_path != old_rna_path);
}
if (fcu->driver == NULL) {
continue;
}
ChannelDriver *driver = fcu->driver;
DriverVar *dvar;
/* driver variables */
for (dvar = driver->variables.first; dvar; dvar = dvar->next) {
/* only change the used targets, since the others will need fixing manually anyway */
DRIVER_TARGETS_USED_LOOPER_BEGIN(dvar)
{
/* rename RNA path */
if (dtar->rna_path && dtar->id) {
const char *old_rna_path = dtar->rna_path;
dtar->rna_path = rna_path_rename_fix(dtar->id, prefix, oldKey, newKey, dtar->rna_path, verify_paths);
is_changed |= (dtar->rna_path != old_rna_path);
}
/* also fix the bone-name (if applicable) */
if (strstr(prefix, "bones")) {
if ( ((dtar->id) && (GS(dtar->id->name) == ID_OB) && (!ref_id || ((Object *)(dtar->id))->data == ref_id)) &&
(dtar->pchan_name[0]) && STREQ(oldName, dtar->pchan_name) )
{
is_changed = true;
BLI_strncpy(dtar->pchan_name, newName, sizeof(dtar->pchan_name));
Drivers Bugfix: Renaming bones now correctly fixes drivers referencing those bones. This includes driver paths and driver variables.
2010-05-17 04:22:41 +00:00
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
}
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
DRIVER_TARGETS_LOOPER_END;
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
}
}
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
return is_changed;
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
}
/* Fix all RNA-Paths for Actions linked to NLA Strips */
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
static bool nlastrips_path_rename_fix(ID *owner_id, const char *prefix, const char *oldName, const char *newName,
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
const char *oldKey, const char *newKey, ListBase *strips, bool verify_paths)
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
{
NlaStrip *strip;
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
bool is_changed = false;
/* Recursively check strips, fixing only actions. */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (strip = strips->first; strip; strip = strip->next) {
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
/* fix strip's action */
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
if (strip->act != NULL) {
is_changed |= fcurves_path_rename_fix(
owner_id, prefix, oldName, newName, oldKey, newKey, &strip->act->curves, verify_paths);
}
/* Ignore own F-Curves, since those are local. */
/* Check sub-strips (if metas) */
is_changed |= nlastrips_path_rename_fix(
owner_id, prefix, oldName, newName, oldKey, newKey, &strip->strips, verify_paths);
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
}
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
return is_changed;
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
}
Cleanup/Style Tweaks to fit rest of code
2017-12-05 17:14:55 +13:00
/* Rename Sub-ID Entities in RNA Paths ----------------------- */
Fix: Joining armatures fixes up the drivers accordingly Finally! At long last, I've gotten this working! This ended up being far trickier to get right than anticipated; the normal remapping API's cannot be used as-is as they will just clobber over subtleties whenever datablock changes are involved. So, for now, we have to duplicate the logic a bit.
2015-01-23 02:33:01 +13:00
/* Fix up the given RNA-Path
*
* This is just an external wrapper for the RNA-Path fixing function,
* with input validity checks on top of the basic method.
*
* NOTE: it is assumed that the structure we're replacing is <prefix><["><name><"]>
* i.e. pose.bones["Bone"]
*/
char *BKE_animsys_fix_rna_path_rename(ID *owner_id, char *old_path, const char *prefix, const char *oldName,
const char *newName, int oldSubscript, int newSubscript, bool verify_paths)
{
char *oldN, *newN;
char *result;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures fixes up the drivers accordingly Finally! At long last, I've gotten this working! This ended up being far trickier to get right than anticipated; the normal remapping API's cannot be used as-is as they will just clobber over subtleties whenever datablock changes are involved. So, for now, we have to duplicate the logic a bit.
2015-01-23 02:33:01 +13:00
/* if no action, no need to proceed */
if (ELEM(NULL, owner_id, old_path)) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
if (G.debug & G_DEBUG) CLOG_WARN(&LOG, "early abort");
Fix: Joining armatures fixes up the drivers accordingly Finally! At long last, I've gotten this working! This ended up being far trickier to get right than anticipated; the normal remapping API's cannot be used as-is as they will just clobber over subtleties whenever datablock changes are involved. So, for now, we have to duplicate the logic a bit.
2015-01-23 02:33:01 +13:00
return old_path;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures fixes up the drivers accordingly Finally! At long last, I've gotten this working! This ended up being far trickier to get right than anticipated; the normal remapping API's cannot be used as-is as they will just clobber over subtleties whenever datablock changes are involved. So, for now, we have to duplicate the logic a bit.
2015-01-23 02:33:01 +13:00
/* Name sanitation logic - copied from BKE_animdata_fix_paths_rename() */
if ((oldName != NULL) && (newName != NULL)) {
/* pad the names with [" "] so that only exact matches are made */
const size_t name_old_len = strlen(oldName);
const size_t name_new_len = strlen(newName);
char *name_old_esc = BLI_array_alloca(name_old_esc, (name_old_len * 2) + 1);
char *name_new_esc = BLI_array_alloca(name_new_esc, (name_new_len * 2) + 1);
BLI_strescape(name_old_esc, oldName, (name_old_len * 2) + 1);
BLI_strescape(name_new_esc, newName, (name_new_len * 2) + 1);
oldN = BLI_sprintfN("[\"%s\"]", name_old_esc);
newN = BLI_sprintfN("[\"%s\"]", name_new_esc);
}
else {
oldN = BLI_sprintfN("[%d]", oldSubscript);
newN = BLI_sprintfN("[%d]", newSubscript);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures fixes up the drivers accordingly Finally! At long last, I've gotten this working! This ended up being far trickier to get right than anticipated; the normal remapping API's cannot be used as-is as they will just clobber over subtleties whenever datablock changes are involved. So, for now, we have to duplicate the logic a bit.
2015-01-23 02:33:01 +13:00
/* fix given path */
Fix: Disable leftover debug prints from earlier work on the rna path renaming/fixing code
2018-01-29 17:16:31 +13:00
if (G.debug & G_DEBUG) printf("%s | %s | oldpath = %p ", oldN, newN, old_path);
Fix: Joining armatures fixes up the drivers accordingly Finally! At long last, I've gotten this working! This ended up being far trickier to get right than anticipated; the normal remapping API's cannot be used as-is as they will just clobber over subtleties whenever datablock changes are involved. So, for now, we have to duplicate the logic a bit.
2015-01-23 02:33:01 +13:00
result = rna_path_rename_fix(owner_id, prefix, oldN, newN, old_path, verify_paths);
Fix: Disable leftover debug prints from earlier work on the rna path renaming/fixing code
2018-01-29 17:16:31 +13:00
if (G.debug & G_DEBUG) printf("path rename result = %p\n", result);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures fixes up the drivers accordingly Finally! At long last, I've gotten this working! This ended up being far trickier to get right than anticipated; the normal remapping API's cannot be used as-is as they will just clobber over subtleties whenever datablock changes are involved. So, for now, we have to duplicate the logic a bit.
2015-01-23 02:33:01 +13:00
/* free the temp names */
MEM_freeN(oldN);
MEM_freeN(newN);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix: Joining armatures fixes up the drivers accordingly Finally! At long last, I've gotten this working! This ended up being far trickier to get right than anticipated; the normal remapping API's cannot be used as-is as they will just clobber over subtleties whenever datablock changes are involved. So, for now, we have to duplicate the logic a bit.
2015-01-23 02:33:01 +13:00
/* return the resulting path - may be the same path again if nothing changed */
return result;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Fix all RNA_Paths in the given Action, relative to the given ID block
Bugfix: Renaming bones now renames the corresponding F-Curves in actions used by Action Constraints
2013-10-22 11:36:48 +00:00
*
* This is just an external wrapper for the F-Curve fixing function,
* with input validity checks on top of the basic method.
*
* NOTE: it is assumed that the structure we're replacing is <prefix><["><name><"]>
* i.e. pose.bones["Bone"]
*/
void BKE_action_fix_paths_rename(ID *owner_id, bAction *act, const char *prefix, const char *oldName,
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
const char *newName, int oldSubscript, int newSubscript, bool verify_paths)
Bugfix: Renaming bones now renames the corresponding F-Curves in actions used by Action Constraints
2013-10-22 11:36:48 +00:00
{
char *oldN, *newN;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Renaming bones now renames the corresponding F-Curves in actions used by Action Constraints
2013-10-22 11:36:48 +00:00
/* if no action, no need to proceed */
if (ELEM(NULL, owner_id, act))
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Renaming bones now renames the corresponding F-Curves in actions used by Action Constraints
2013-10-22 11:36:48 +00:00
/* Name sanitation logic - copied from BKE_animdata_fix_paths_rename() */
if ((oldName != NULL) && (newName != NULL)) {
/* pad the names with [" "] so that only exact matches are made */
const size_t name_old_len = strlen(oldName);
const size_t name_new_len = strlen(newName);
char *name_old_esc = BLI_array_alloca(name_old_esc, (name_old_len * 2) + 1);
char *name_new_esc = BLI_array_alloca(name_new_esc, (name_new_len * 2) + 1);
BLI_strescape(name_old_esc, oldName, (name_old_len * 2) + 1);
BLI_strescape(name_new_esc, newName, (name_new_len * 2) + 1);
oldN = BLI_sprintfN("[\"%s\"]", name_old_esc);
newN = BLI_sprintfN("[\"%s\"]", name_new_esc);
}
else {
oldN = BLI_sprintfN("[%d]", oldSubscript);
newN = BLI_sprintfN("[%d]", newSubscript);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Renaming bones now renames the corresponding F-Curves in actions used by Action Constraints
2013-10-22 11:36:48 +00:00
/* fix paths in action */
fcurves_path_rename_fix(owner_id, prefix, oldName, newName, oldN, newN, &act->curves, verify_paths);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Renaming bones now renames the corresponding F-Curves in actions used by Action Constraints
2013-10-22 11:36:48 +00:00
/* free the temp names */
MEM_freeN(oldN);
MEM_freeN(newN);
}
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
/* Fix all RNA-Paths in the AnimData block used by the given ID block
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
* NOTE: it is assumed that the structure we're replacing is <prefix><["><name><"]>
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
* i.e. pose.bones["Bone"]
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
*/
Fix [#30709] Renaming a bone renames all drivers' targets using a bone of that name, regardless of the armature. This fix adds a "ref_id" ID pointer to BKE_all_animdata_fix_paths_rename() & co, which is the ID against which prefix+oldName/NewName is "applied", currently only used for drivers' bones targets. Just pass NULL to get same behavior as previously. A bit annoying to make such a change for such a specific case, but there seems to be no other way to go... :/
2012-03-30 13:04:29 +00:00
void BKE_animdata_fix_paths_rename(ID *owner_id, AnimData *adt, ID *ref_id, const char *prefix, const char *oldName,
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
const char *newName, int oldSubscript, int newSubscript, bool verify_paths)
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
{
NlaTrack *nlt;
Fixes for Path-Renaming Fix: * Now the old/new names get tagged with [" "] before the search and replace operation, which should alleviate problems with searching for 'bone' and ending up with all instances of 'boney' 'boney.r' etc. also getting renamed. * Cleaned up some compiler warnings, and removed an unused function from an earlier attempt at this work.
2009-10-20 04:07:57 +00:00
char *oldN, *newN;
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
/* If no AnimData, no need to proceed. */
if (ELEM(NULL, owner_id, adt)) {
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
return;
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
}
bool is_self_changed = false;
/* Name sanitation logic - shared with BKE_action_fix_paths_rename(). */
Drivers Bugfix: Renaming bones now correctly fixes drivers referencing those bones. This includes driver paths and driver variables.
2010-05-17 04:22:41 +00:00
if ((oldName != NULL) && (newName != NULL)) {
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
/* Pad the names with [" "] so that only exact matches are made. */
use string escaping when renaming animation paths - BKE_animdata_fix_paths_rename()
2013-04-23 20:24:10 +00:00
const size_t name_old_len = strlen(oldName);
const size_t name_new_len = strlen(newName);
char *name_old_esc = BLI_array_alloca(name_old_esc, (name_old_len * 2) + 1);
char *name_new_esc = BLI_array_alloca(name_new_esc, (name_new_len * 2) + 1);
BLI_strescape(name_old_esc, oldName, (name_old_len * 2) + 1);
BLI_strescape(name_new_esc, newName, (name_new_len * 2) + 1);
oldN = BLI_sprintfN("[\"%s\"]", name_old_esc);
newN = BLI_sprintfN("[\"%s\"]", name_new_esc);
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
Drivers Bugfix: Renaming bones now correctly fixes drivers referencing those bones. This includes driver paths and driver variables.
2010-05-17 04:22:41 +00:00
else {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
oldN = BLI_sprintfN("[%d]", oldSubscript);
newN = BLI_sprintfN("[%d]", newSubscript);
Fix [#21165] Moved textures don't move the animation curves
2010-03-16 07:44:57 +00:00
}
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
/* Active action and temp action. */
if (adt->action != NULL) {
if (fcurves_path_rename_fix(owner_id, prefix, oldName, newName,
oldN, newN, &adt->action->curves, verify_paths))
{
DEG_id_tag_update(&adt->action->id, ID_RECALC_COPY_ON_WRITE);
}
}
if (adt->tmpact) {
if (fcurves_path_rename_fix(owner_id, prefix, oldName, newName,
oldN, newN, &adt->tmpact->curves, verify_paths))
{
DEG_id_tag_update(&adt->tmpact->id, ID_RECALC_COPY_ON_WRITE);
}
}
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
/* Drivers - Drivers are really F-Curves */
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
is_self_changed |= drivers_path_rename_fix(
owner_id, ref_id, prefix, oldName, newName, oldN, newN, &adt->drivers, verify_paths);
2.5 - Animation Tweaks * delta-transforms for objects should work again. These were basically extra transforms that could get added on top of the values calculated from animation values. * Added some skeleton code for fixing paths when some data needs to be renamed.
2009-09-22 11:45:30 +00:00
/* NLA Data - Animation Data for Strips */
Fix T60686: Renaming an animated bone breaks its animation After rename is done we need to make sure all copies of corresponding datablocks are updated in all dependency graphs: otherwise bone will have a new name, but animation will still be using an old one.
2019-01-22 14:50:58 +01:00
for (nlt = adt->nla_tracks.first; nlt; nlt = nlt->next) {
is_self_changed |= nlastrips_path_rename_fix(
owner_id, prefix, oldName, newName, oldN, newN, &nlt->strips, verify_paths);
}
/* Tag owner ID if it */
if (is_self_changed) {
DEG_id_tag_update(owner_id, ID_RECALC_COPY_ON_WRITE);
}
Fixes for Path-Renaming Fix: * Now the old/new names get tagged with [" "] before the search and replace operation, which should alleviate problems with searching for 'bone' and ending up with all instances of 'boney' 'boney.r' etc. also getting renamed. * Cleaned up some compiler warnings, and removed an unused function from an earlier attempt at this work.
2009-10-20 04:07:57 +00:00
/* free the temp names */
MEM_freeN(oldN);
MEM_freeN(newN);
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
}
Cleanup/Style Tweaks to fit rest of code
2017-12-05 17:14:55 +13:00
/* Remove FCurves with Prefix -------------------------------------- */
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
/* Check RNA-Paths for a list of F-Curves */
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
static bool fcurves_path_remove_fix(const char *prefix, ListBase *curves)
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
{
FCurve *fcu, *fcn;
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
bool any_removed = false;
if (!prefix) return any_removed;
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
/* we need to check every curve... */
for (fcu = curves->first; fcu; fcu = fcn) {
fcn = fcu->next;
if (fcu->rna_path) {
style edits and use macro for prefix check
2013-10-01 16:40:11 +00:00
if (STRPREFIX(fcu->rna_path, prefix)) {
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
BLI_remlink(curves, fcu);
free_fcurve(fcu);
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
any_removed = true;
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
}
}
}
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
return any_removed;
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
}
/* Check RNA-Paths for a list of F-Curves */
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
static bool nlastrips_path_remove_fix(const char *prefix, ListBase *strips)
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
{
NlaStrip *strip;
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
bool any_removed = false;
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
/* recursively check strips, fixing only actions... */
for (strip = strips->first; strip; strip = strip->next) {
/* fix strip's action */
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
if (strip->act) {
any_removed |= fcurves_path_remove_fix(prefix, &strip->act->curves);
}
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
/* check sub-strips (if metas) */
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
any_removed |= nlastrips_path_remove_fix(prefix, &strip->strips);
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
}
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
return any_removed;
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
}
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
bool BKE_animdata_fix_paths_remove(ID *id, const char *prefix)
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
{
/* Only some ID-blocks have this info for now, so we cast the
* types that do to be of type IdAdtTemplate
*/
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
if (!id_can_have_animdata(id)) {
return false;
}
bool any_removed = false;
IdAdtTemplate *iat = (IdAdtTemplate *)id;
AnimData *adt = iat->adt;
/* check if there's any AnimData to start with */
if (adt) {
/* free fcurves */
if (adt->action != NULL) {
any_removed |= fcurves_path_remove_fix(prefix, &adt->action->curves);
}
if (adt->tmpact != NULL) {
any_removed |= fcurves_path_remove_fix(prefix, &adt->tmpact->curves);
}
/* free drivers - stored as a list of F-Curves */
any_removed |= fcurves_path_remove_fix(prefix, &adt->drivers);
/* NLA Data - Animation Data for Strips */
for (NlaTrack *nlt = adt->nla_tracks.first; nlt; nlt = nlt->next) {
any_removed |= nlastrips_path_remove_fix(prefix, &nlt->strips);
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
}
}
Return truth when animation fix changed animation This can be used to inform higher level modules that animation is changed and that dependency graph likely requires relations update now.
2018-11-23 16:45:09 +01:00
return any_removed;
bugfix [#32346] Node animation, removing nodes keeps FCurves. The same bug happens for modifiers, but better to address it separately. Contribution and review by Lukas Toenne and Brecht van Lommel
2013-10-01 16:15:52 +00:00
}
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
/* Apply Op to All FCurves in Database --------------------------- */
/* "User-Data" wrapper used by BKE_fcurves_main_cb() */
typedef struct AllFCurvesCbWrapper {
ID_FCurve_Edit_Callback func; /* Operation to apply on F-Curve */
void *user_data; /* Custom data for that operation */
} AllFCurvesCbWrapper;
/* Helper for adt_apply_all_fcurves_cb() - Apply wrapped operator to list of F-Curves */
static void fcurves_apply_cb(ID *id, ListBase *fcurves, ID_FCurve_Edit_Callback func, void *user_data)
{
FCurve *fcu;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
for (fcu = fcurves->first; fcu; fcu = fcu->next) {
func(id, fcu, user_data);
}
}
/* Helper for adt_apply_all_fcurves_cb() - Recursively go through each NLA strip */
static void nlastrips_apply_all_curves_cb(ID *id, ListBase *strips, AllFCurvesCbWrapper *wrapper)
{
NlaStrip *strip;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
for (strip = strips->first; strip; strip = strip->next) {
/* fix strip's action */
if (strip->act) {
fcurves_apply_cb(id, &strip->act->curves, wrapper->func, wrapper->user_data);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
/* check sub-strips (if metas) */
nlastrips_apply_all_curves_cb(id, &strip->strips, wrapper);
}
}
/* Helper for BKE_fcurves_main_cb() - Dispatch wrapped operator to all F-Curves */
Version patching fixes for F-Curves (as required for fixes for T48988 and T52009) * For the T48988 fix (i.e. separate Ease In/Out properties for Bendy Bones in Edit vs Pose modes), old animation data needed to be patched to use the new property names. This is needed to partially fix some of the issues in T53356 (though the Rigify code itself still needs to be patched). * For the T52009 fix, old files needed to have the frame_start and frame_end properties on the FModifier (base-class) updated to match that of the FMod_Stepped type-specific class. This wasn't done in the earlier commit since it wasn't worth going through all animation data just for the sake of updating these relatively-rare settings, but since we're doing it anyway now, it makes sense to include this here.
2017-12-06 00:54:39 +13:00
static void adt_apply_all_fcurves_cb(ID *id, AnimData *adt, void *wrapper_data)
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
{
Version patching fixes for F-Curves (as required for fixes for T48988 and T52009) * For the T48988 fix (i.e. separate Ease In/Out properties for Bendy Bones in Edit vs Pose modes), old animation data needed to be patched to use the new property names. This is needed to partially fix some of the issues in T53356 (though the Rigify code itself still needs to be patched). * For the T52009 fix, old files needed to have the frame_start and frame_end properties on the FModifier (base-class) updated to match that of the FMod_Stepped type-specific class. This wasn't done in the earlier commit since it wasn't worth going through all animation data just for the sake of updating these relatively-rare settings, but since we're doing it anyway now, it makes sense to include this here.
2017-12-06 00:54:39 +13:00
AllFCurvesCbWrapper *wrapper = wrapper_data;
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
NlaTrack *nlt;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
if (adt->action) {
fcurves_apply_cb(id, &adt->action->curves, wrapper->func, wrapper->user_data);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
if (adt->tmpact) {
fcurves_apply_cb(id, &adt->tmpact->curves, wrapper->func, wrapper->user_data);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
/* free drivers - stored as a list of F-Curves */
fcurves_apply_cb(id, &adt->drivers, wrapper->func, wrapper->user_data);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
/* NLA Data - Animation Data for Strips */
for (nlt = adt->nla_tracks.first; nlt; nlt = nlt->next) {
nlastrips_apply_all_curves_cb(id, &nlt->strips, wrapper);
}
}
Depsgraph: Keep objects which has animated visibility This allows dependency graph to evaluate drivers of those objects and put them to a correct state. It will increase memory usage since now we can no longer save it by skipping copy-on-write for such objects. It will also currently make things slower, because we do not have granular enough visibility update of components in the dependency graph. Can do it later when the rest of the changes are finished. This commit does not update restriction flags on the base, since that is somewhat tricky to do currently: need to somehow see whether object is disabled due to flags on collection or due to own flags. Differential Revision: https://developer.blender.org/D4419
2019-02-27 15:15:26 +01:00
void BKE_fcurves_id_cb(ID *id, ID_FCurve_Edit_Callback func, void *user_data)
{
AnimData *adt = BKE_animdata_from_id(id);
if (adt != NULL) {
AllFCurvesCbWrapper wrapper = {func, user_data};
adt_apply_all_fcurves_cb(id, adt, &wrapper);
}
}
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
/* apply the given callback function on all F-Curves attached to data in main database */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
void BKE_fcurves_main_cb(Main *bmain, ID_FCurve_Edit_Callback func, void *user_data)
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
{
/* Wrap F-Curve operation stuff to pass to the general AnimData-level func */
AllFCurvesCbWrapper wrapper = {func, user_data};
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
/* Use the AnimData-based function so that we don't have to reimplement all that stuff */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
BKE_animdata_main_cb(bmain, adt_apply_all_fcurves_cb, &wrapper);
Added BKE_fcurves_main_cb(), a wrapper around BKE_animdata_main_cb to make it easier to apply fixes to all F-Curves in a file
2017-12-05 17:16:05 +13:00
}
A few minor code cleanup tweaks for recent commits in animation code, to better follow conventions elsewhere here :)
2010-01-30 05:08:42 +00:00
/* Whole Database Ops -------------------------------------------- */
/* apply the given callback function on all data in main database */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
void BKE_animdata_main_cb(Main *bmain, ID_AnimData_Edit_Callback func, void *user_data)
deleting objects which were driver targets would crash blender. added a utility function BKE_animdata_main_cb which loops over all AnimData's of all ID's
2010-01-29 21:16:21 +00:00
{
ID *id;
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* standard data version */
deleting objects which were driver targets would crash blender. added a utility function BKE_animdata_main_cb which loops over all AnimData's of all ID's
2010-01-29 21:16:21 +00:00
#define ANIMDATA_IDS_CB(first) \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (id = first; id; id = id->next) { \
AnimData *adt = BKE_animdata_from_id(id); \
A few minor code cleanup tweaks for recent commits in animation code, to better follow conventions elsewhere here :)
2010-01-30 05:08:42 +00:00
if (adt) func(id, adt, user_data); \
style cleanup: defines with braces
2012-05-27 20:13:59 +00:00
} (void)0
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* "embedded" nodetree cases (i.e. scene/material/texture->nodetree) */
#define ANIMDATA_NODETREE_IDS_CB(first, NtId_Type) \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (id = first; id; id = id->next) { \
AnimData *adt = BKE_animdata_from_id(id); \
NtId_Type *ntp = (NtId_Type *)id; \
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
if (ntp->nodetree) { \
Fix T39623: deleting an object crashes
2014-04-07 20:24:20 +10:00
AnimData *adt2 = BKE_animdata_from_id((ID *)ntp->nodetree); \
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
if (adt2) func(id, adt2, user_data); \
} \
if (adt) func(id, adt, user_data); \
style cleanup: defines with braces
2012-05-27 20:13:59 +00:00
} (void)0
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* nodes */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->nodetree.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* textures */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_NODETREE_IDS_CB(bmain->tex.first, Tex);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Cleanup: rename lamp -> light
2019-02-27 12:02:02 +11:00
/* lights */
DNA: rename Lamp -> Light - BKE_lamp -> BKE_light - Main.lamp -> light
2019-02-27 10:46:48 +11:00
ANIMDATA_NODETREE_IDS_CB(bmain->light.first, Light);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* materials */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_NODETREE_IDS_CB(bmain->mat.first, Material);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* cameras */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->camera.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* shapekeys */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->key.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* metaballs */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->mball.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* curves */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->curve.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* armatures */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->armature.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* lattices */
Cleanup: Main struct member names Rename latt to lattice and don't use plural names.
2019-02-27 11:14:41 +11:00
ANIMDATA_IDS_CB(bmain->lattice.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* meshes */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->mesh.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* particles */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->particle.first);
3D Audio GSoC: Adds new speaker object type. Notes: * Needs some nice icons * Quickily review by Joshua Leung (5 mins) * Properties UI updated (with help of Thomans Dinges) * Speakers have their own theme color * No real audio functionality yet. * Minor bug regarding lamps/lattices fixed in interface_templates.c I personality tested: * Creation, Deletion, Duplication * Saving, Loading * Library linking (incl. make local) * Tracking * Dope Sheet, Outliner * Animation * Drawing (incl. Theme)
2011-08-01 11:44:20 +00:00
/* speakers */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->speaker.first);
3D Audio GSoC: Adds new speaker object type. Notes: * Needs some nice icons * Quickily review by Joshua Leung (5 mins) * Properties UI updated (with help of Thomans Dinges) * Speakers have their own theme color * No real audio functionality yet. * Minor bug regarding lamps/lattices fixed in interface_templates.c I personality tested: * Creation, Deletion, Duplication * Saving, Loading * Library linking (incl. make local) * Tracking * Dope Sheet, Outliner * Animation * Drawing (incl. Theme)
2011-08-01 11:44:20 +00:00
Missed this changes needed to fully support animation data in movie clips. Thanks to Joshua pointed into missed changes!
2012-02-17 10:54:21 +00:00
/* movie clips */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->movieclip.first);
Missed this changes needed to fully support animation data in movie clips. Thanks to Joshua pointed into missed changes!
2012-02-17 10:54:21 +00:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* objects */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->object.first);
mask mode for clip editor developed by Sergey Sharybin, Pete Larabell and myself. see: http://wiki.blender.org/index.php/User:Nazg-gul/MaskEditor note - mask editing tools need continued development, feather option is not working 100%
2012-06-04 16:42:58 +00:00
/* masks */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->mask.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* worlds */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_NODETREE_IDS_CB(bmain->world.first, World);
mask mode for clip editor developed by Sergey Sharybin, Pete Larabell and myself. see: http://wiki.blender.org/index.php/User:Nazg-gul/MaskEditor note - mask editing tools need continued development, feather option is not working 100%
2012-06-04 16:42:58 +00:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* scenes */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_NODETREE_IDS_CB(bmain->scene.first, Scene);
Another big patch set by Bastien Montagne, thanks a lot! * Made Freestyle optional (turned on by default). * Fix for missing bpath.c updates in the previous merge of trunk changes.
2012-12-20 07:57:26 +00:00
Merged changes in the trunk up to revision 34010.
2011-01-02 18:34:32 +00:00
/* line styles */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->linestyle.first);
Cleanup: trailing space for blenkernel
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 */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
ANIMDATA_IDS_CB(bmain->gpencil.first);
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
New Grease Pencil object for 2D animation This commit merge the full development done in greasepencil-object branch and include mainly the following features. - New grease pencil object. - New drawing engine. - New grease pencil modes Draw/Sculpt/Edit and Weight Paint. - New brushes for grease pencil. - New modifiers for grease pencil. - New shaders FX. - New material system (replace old palettes and colors). - Split of annotations (old grease pencil) and new grease pencil object. - UI adapted to blender 2.8. You can get more info here: https://code.blender.org/2017/12/drawing-2d-animation-in-blender-2-8/ https://code.blender.org/2018/07/grease-pencil-status-update/ This is the result of nearly two years of development and I want thanks firstly the other members of the grease pencil team: Daniel M. Lara, Matias Mendiola and Joshua Leung for their support, ideas and to keep working in the project all the time, without them this project had been impossible. Also, I want thanks other Blender developers for their help, advices and to be there always to help me, and specially to Clément Foucault, Dalai Felinto, Pablo Vázquez and Campbell Barton.
2018-07-31 10:22:19 +02:00
/* palettes */
Cleanup: Main struct member names Rename latt to lattice and don't use plural names.
2019-02-27 11:14:41 +11:00
ANIMDATA_IDS_CB(bmain->palette.first);
New Grease Pencil object for 2D animation This commit merge the full development done in greasepencil-object branch and include mainly the following features. - New grease pencil object. - New drawing engine. - New grease pencil modes Draw/Sculpt/Edit and Weight Paint. - New brushes for grease pencil. - New modifiers for grease pencil. - New shaders FX. - New material system (replace old palettes and colors). - Split of annotations (old grease pencil) and new grease pencil object. - UI adapted to blender 2.8. You can get more info here: https://code.blender.org/2017/12/drawing-2d-animation-in-blender-2-8/ https://code.blender.org/2018/07/grease-pencil-status-update/ This is the result of nearly two years of development and I want thanks firstly the other members of the grease pencil team: Daniel M. Lara, Matias Mendiola and Joshua Leung for their support, ideas and to keep working in the project all the time, without them this project had been impossible. Also, I want thanks other Blender developers for their help, advices and to be there always to help me, and specially to Clément Foucault, Dalai Felinto, Pablo Vázquez and Campbell Barton.
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 */
Cleanup: Main struct member names Rename latt to lattice and don't use plural names.
2019-02-27 11:14:41 +11:00
ANIMDATA_IDS_CB(bmain->cachefile.first);
White space fixes (to make a diff from the trunk cleaner).
2013-04-05 16:53:24 +00:00
}
deleting objects which were driver targets would crash blender. added a utility function BKE_animdata_main_cb which loops over all AnimData's of all ID's
2010-01-29 21:16:21 +00:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* Fix all RNA-Paths throughout the database (directly access the Global.main version)
* NOTE: it is assumed that the structure we're replacing is <prefix><["><name><"]>
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
* i.e. pose.bones["Bone"]
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
*/
deleting objects which were driver targets would crash blender. added a utility function BKE_animdata_main_cb which loops over all AnimData's of all ID's
2010-01-29 21:16:21 +00:00
/* TODO: use BKE_animdata_main_cb for looping over all data */
Cleanup: use BKE_animdata_* prefix
2015-04-04 15:13:56 +11:00
void BKE_animdata_fix_paths_rename_all(ID *ref_id, const char *prefix, const char *oldName, const char *newName)
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
{
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
Main *bmain = G.main; /* XXX UGLY! */
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
ID *id;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* macro for less typing
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - whether animdata exists is checked for by the main renaming callback, though taking
* this outside of the function may make things slightly faster?
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
*/
#define RENAMEFIX_ANIM_IDS(first) \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (id = first; id; id = id->next) { \
AnimData *adt = BKE_animdata_from_id(id); \
BKE_animdata_fix_paths_rename(id, adt, ref_id, prefix, oldName, newName, 0, 0, 1); \
style cleanup: defines with braces
2012-05-27 20:13:59 +00:00
} (void)0
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* another version of this macro for nodetrees */
#define RENAMEFIX_ANIM_NODETREE_IDS(first, NtId_Type) \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (id = first; id; id = id->next) { \
AnimData *adt = BKE_animdata_from_id(id); \
NtId_Type *ntp = (NtId_Type *)id; \
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
if (ntp->nodetree) { \
Fix T40727: Renaming nodes did not correctly fix animation paths.
2014-06-21 06:45:48 +02:00
AnimData *adt2 = BKE_animdata_from_id((ID *)ntp->nodetree); \
BKE_animdata_fix_paths_rename((ID *)ntp->nodetree, adt2, ref_id, prefix, oldName, newName, 0, 0, 1); \
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
} \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
BKE_animdata_fix_paths_rename(id, adt, ref_id, prefix, oldName, newName, 0, 0, 1); \
style cleanup: defines with braces
2012-05-27 20:13:59 +00:00
} (void)0
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* nodes */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->nodetree.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* textures */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_NODETREE_IDS(bmain->tex.first, Tex);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Cleanup: rename lamp -> light
2019-02-27 12:02:02 +11:00
/* lights */
DNA: rename Lamp -> Light - BKE_lamp -> BKE_light - Main.lamp -> light
2019-02-27 10:46:48 +11:00
RENAMEFIX_ANIM_NODETREE_IDS(bmain->light.first, Light);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* materials */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_NODETREE_IDS(bmain->mat.first, Material);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* cameras */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->camera.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* shapekeys */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->key.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* metaballs */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->mball.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* curves */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->curve.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* armatures */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->armature.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Consistency cleanups for AnimData stuff: Some AnimData looping functions were not updated to take into account the addition of AnimData for some additional datatypes (i.e. meshes and lattices) as well as the changes to make nested nodetrees (i.e. for Material and Texture nodes).
2010-12-29 05:20:19 +00:00
/* lattices */
Cleanup: Main struct member names Rename latt to lattice and don't use plural names.
2019-02-27 11:14:41 +11:00
RENAMEFIX_ANIM_IDS(bmain->lattice.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* meshes */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->mesh.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* particles */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->particle.first);
3D Audio GSoC: Adds new speaker object type. Notes: * Needs some nice icons * Quickily review by Joshua Leung (5 mins) * Properties UI updated (with help of Thomans Dinges) * Speakers have their own theme color * No real audio functionality yet. * Minor bug regarding lamps/lattices fixed in interface_templates.c I personality tested: * Creation, Deletion, Duplication * Saving, Loading * Library linking (incl. make local) * Tracking * Dope Sheet, Outliner * Animation * Drawing (incl. Theme)
2011-08-01 11:44:20 +00:00
/* speakers */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->speaker.first);
3D Audio GSoC: Adds new speaker object type. Notes: * Needs some nice icons * Quickily review by Joshua Leung (5 mins) * Properties UI updated (with help of Thomans Dinges) * Speakers have their own theme color * No real audio functionality yet. * Minor bug regarding lamps/lattices fixed in interface_templates.c I personality tested: * Creation, Deletion, Duplication * Saving, Loading * Library linking (incl. make local) * Tracking * Dope Sheet, Outliner * Animation * Drawing (incl. Theme)
2011-08-01 11:44:20 +00:00
Missed this changes needed to fully support animation data in movie clips. Thanks to Joshua pointed into missed changes!
2012-02-17 10:54:21 +00:00
/* movie clips */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->movieclip.first);
Missed this changes needed to fully support animation data in movie clips. Thanks to Joshua pointed into missed changes!
2012-02-17 10:54:21 +00:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* objects */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->object.first);
mask mode for clip editor developed by Sergey Sharybin, Pete Larabell and myself. see: http://wiki.blender.org/index.php/User:Nazg-gul/MaskEditor note - mask editing tools need continued development, feather option is not working 100%
2012-06-04 16:42:58 +00:00
/* masks */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->mask.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* worlds */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_NODETREE_IDS(bmain->world.first, World);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
A step toward a new user-friendly GUI for manipulating line style parameters. This commit is just meant to give the new GUI framework a concrete shape. There is no usefulness in newly introduced elements at the moment. Freestyle options in render layers now include a pull-down menu named Control Mode that allows you to choose either the Python Scripting or Parameter Editor mode. The Python Scripting mode is the conventional way of controlling Freestyle by directly using style modules written in Python. The Parameter Editor is a new control mode that is intended to be used by everyone without relying on Python programming. In the Parameter Editor mode, you can specify multiple line sets for each render layer. A line set defines feature edge selection criteria, as well as a line style for drawing the selected feature edges using specific line stylization parameters. Line style is a new datablock type, meaning that a line style can be shared by multiple line sets (possibly those in different render layers in different scenes). Much more additions are anticipated in subsequent commits to implement UI controls for specifying feature edge selection criteria and line stylization parameters.
2010-06-25 22:45:42 +00:00
/* linestyles */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->linestyle.first);
Cleanup: trailing space for blenkernel
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 */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_IDS(bmain->gpencil.first);
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 */
Cleanup: Main struct member names Rename latt to lattice and don't use plural names.
2019-02-27 11:14:41 +11:00
RENAMEFIX_ANIM_IDS(bmain->cachefile.first);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #19663: Renaming named data doesn't fix F-Curves RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-10-20 03:44:35 +00:00
/* scenes */
Cleanup: remove some G.main from ED's animsys. The easy ones - there some much, much trickier to tackle there...
2018-06-12 12:28:14 +02:00
RENAMEFIX_ANIM_NODETREE_IDS(bmain->scene.first, Scene);
A big cleaning patch by Bastien Montagne (thanks a lot!) * Split and moved Cycles’ render layers panels into the render_layer context as well (would be nice to hide this context when not needed, e.g. with the BGE, but this is not so easy to do nicely...). * Fixed some inconsistencies with trunk (probably due to svn merge glitches) using r52858 as reference. Also recovered the missing release/bin/blender-softwaregl file. * A bunch of style code fixes in Blender's own code (not Freestyle itself yet): line lengths, spaces around operators, block formatting, headers, etc. In rna_linestyle.c, color_blend_items was replaced by ramp_blend_items (exported from rna_material.c).
2012-12-11 22:00:22 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* *********************************** */
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* KeyingSet API */
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
/* Finding Tools --------------------------- */
/* Find the first path that matches the given criteria */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: do we want some method to perform partial matches too? */
style cleanup: whitespace
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, int UNUSED(group_mode))
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
{
KS_Path *ksp;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
/* sanity checks */
Defines: replace ELEM3-16 with ELEM(...), that can take varargs
2014-07-20 01:30:29 +10:00
if (ELEM(NULL, ks, rna_path, id))
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* loop over paths in the current KeyingSet, finding the first one where all settings match
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
* (i.e. the first one where none of the checks fail and equal 0)
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (ksp = ks->paths.first; ksp; ksp = ksp->next) {
short eq_id = 1, eq_path = 1, eq_index = 1, eq_group = 1;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
/* id */
PyKeyingSet Bugfixes: * With multiple objects selected, only one of the objects got keyframed. The code which was checking for duplicate paths was wrongly assuming to ignore the ID-block used still. * Not registering a Keying Set as 'builtin' would crash on startup. I've made all Keying Sets fallback to adding as if they were local for now, but a better solution is coming soon. * Fixed a typo in RNA function wrappers for the generator callback, since it was looking for the iterator only. This doesn't seem to have caused any problems (thankfully).
2010-03-17 11:34:27 +00:00
if (id != ksp->id)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
eq_id = 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
/* path */
Cleanup: strcmp/strncmp -> STREQ/STREQLEN (in boolean usage). Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)' and 'strcmp(foo, bar) == 0' in several places...
2015-01-26 16:03:11 +01:00
if ((ksp->rna_path == NULL) || !STREQ(rna_path, ksp->rna_path))
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
eq_path = 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Added options to add/remove properties from the active Keying Set to the RMB menu (and also via KKEY and ALT-K respectively)
2009-09-04 07:26:32 +00:00
/* index - need to compare whole-array setting too... */
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
if (ksp->array_index != array_index)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
eq_index = 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
/* group */
if (group_name) {
style cleanup
2012-07-07 22:51:57 +00:00
/* FIXME: these checks need to be coded... for now, it's not too important though */
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
/* if all aspects are ok, return */
if (eq_id && eq_path && eq_index && eq_group)
return ksp;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
/* none found */
return NULL;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* Defining Tools --------------------------- */
/* Used to create a new 'custom' KeyingSet for the user, that will be automatically added to the stack */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
KeyingSet *BKE_keyingset_add(ListBase *list, const char idname[], const char name[], short flag, short keyingflag)
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
{
KeyingSet *ks;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* allocate new KeyingSet */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ks = MEM_callocN(sizeof(KeyingSet), "KeyingSet");
tedious string copying changes - use sizeof() in more places. - fixed some off by 1 bugs copying strings. setting curve font family for instance was 1 char too short. - replace strncpy and strcpy with BLI_strncpy
2010-11-05 07:35:21 +00:00
More new data names translation (most cases should be covered now). Also done a few cleanup here and there...
2013-03-25 08:29:06 +00:00
BLI_strncpy(ks->idname, (idname) ? idname : (name) ? name : DATA_("KeyingSet"), sizeof(ks->idname));
BLI_strncpy(ks->name, (name) ? name : (idname) ? idname : DATA_("Keying Set"), sizeof(ks->name));
tedious string copying changes - use sizeof() in more places. - fixed some off by 1 bugs copying strings. setting curve font family for instance was 1 char too short. - replace strncpy and strcpy with BLI_strncpy
2010-11-05 07:35:21 +00:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ks->flag = flag;
ks->keyingflag = keyingflag;
Fix T38619: Confusing logic for Keying Set keyframing Settings The logic used for determining whether certain keyframing settings (i.e. visual, only needed, xyz -> rgb) got applied was wonky. The original intention here was that the Keying Set settings would override the global settings, and the path settings would override what was used for the Keying Set. However, that was not happening in all cases previously, as it was only possible to add flags and not to turn them off. This commit fixes that by introducing separate toggles to control whether the Keying Set/Path's settings override the settings inherited from its parent (i.e. the Keying Set for the Path, and the User Prefs for the Keying Set). The icons used for these toggles could get revised a bit (we need something which communicates "override this"; the current one is the closest I could find) WARNING: If you have old keying sets, this may cause some breakage!
2015-01-27 02:09:50 +13:00
ks->keyingoverride = keyingflag; /* NOTE: assume that if one is set one way, the other should be too, so that it'll work */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* add KeyingSet to list */
BLI_addtail(list, ks);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Harmless formatting tweaks
2012-11-06 06:29:40 +00:00
/* Make sure KeyingSet has a unique idname */
More new data names translation (most cases should be covered now). Also done a few cleanup here and there...
2013-03-25 08:29:06 +00:00
BLI_uniquename(list, ks, DATA_("KeyingSet"), '.', offsetof(KeyingSet, idname), sizeof(ks->idname));
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Harmless formatting tweaks
2012-11-06 06:29:40 +00:00
/* Make sure KeyingSet has a unique label (this helps with identification) */
More new data names translation (most cases should be covered now). Also done a few cleanup here and there...
2013-03-25 08:29:06 +00:00
BLI_uniquename(list, ks, DATA_("Keying Set"), '.', offsetof(KeyingSet, name), sizeof(ks->name));
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* return new KeyingSet for further editing */
return ks;
}
== 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
/* Add a path to a KeyingSet. Nothing is returned for now...
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
* Checks are performed to ensure that destination is appropriate for the KeyingSet in question
*/
style cleanup: whitespace
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)
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
{
KS_Path *ksp;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* sanity checks */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, ks, rna_path)) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "no Keying Set and/or RNA Path to add path with");
== 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 NULL;
2.5 - Keying Sets API (now usable from Py-Scripts) Wrapped the Keying Sets API with RNA Functions so that they can now be called from Py-Scripts. This will ultimately be useful for riggers to create Keying Sets which can get loaded up/created for animators to use after importing their rig. I've created a demo for this, which can be found at: http://www.pasteall.org/blend/552 Notes: - Kazanbas, I've had to create a rna_scene_api.c here to hold some of the relevant functions. Hopefully this won't cause you too much pain when you do your next merge from 2.5 to your branch ;) - I've noticed that there seem to be a few cases mentioned in the demo which don't totally work yet. I'll commit some fixes for those later.
2009-08-25 04:05:37 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +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 */
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
if (id == NULL) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "No ID provided for Keying Set Path");
== 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 NULL;
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
/* don't add if there is already a matching KS_Path in the KeyingSet */
* Renaming some Keying Sets API functions to make the terminology more consistent in the UI * Fixed bug with hotkeys for adding properties to Keying Sets using the KKEY over the relevant buttons. Was calling the remove callback instead.
2010-02-27 02:03:33 +00:00
if (BKE_keyingset_find_path(ks, id, group_name, rna_path, array_index, groupmode)) {
move debug flag into its own global var (G.debug), split up debug options. --debug --debug-ffmpeg --debug-python --debug-events --debug-wm This makes debug output easier to read - event debug prints would flood output too much before. For convenience: --debug-all turns all debug flags on (works as --debug did before). also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
2012-03-31 00:59:17 +00:00
if (G.debug & G_DEBUG)
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "destination already exists in Keying Set");
== 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 NULL;
2.5 - Keying Sets API (now usable from Py-Scripts) Wrapped the Keying Sets API with RNA Functions so that they can now be called from Py-Scripts. This will ultimately be useful for riggers to create Keying Sets which can get loaded up/created for animators to use after importing their rig. I've created a demo for this, which can be found at: http://www.pasteall.org/blend/552 Notes: - Kazanbas, I've had to create a rna_scene_api.c here to hold some of the relevant functions. Hopefully this won't cause you too much pain when you do your next merge from 2.5 to your branch ;) - I've noticed that there seem to be a few cases mentioned in the demo which don't totally work yet. I'll commit some fixes for those later.
2009-08-25 04:05:37 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* allocate a new KeyingSet Path */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ksp = MEM_callocN(sizeof(KS_Path), "KeyingSet Path");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* just store absolute info */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ksp->id = id;
== 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
if (group_name)
Quiet warnings from last commit. Janne: could you check if ptcache_file_pointers_seek() & ptcache_read_init() can be removed?
2011-01-02 10:13:17 +00:00
BLI_strncpy(ksp->group, group_name, sizeof(ksp->group));
== 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
else
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ksp->group[0] = '\0';
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato Bugfixes: * Copying objects with animation data now works correctly. Previously, actions were not getting copied correctly, leading to loss of data in some cases. * Action and Graph editors now display the name of the Action concerned (for 'Action' folder channels), making it easier to tell which AnimData blocks are sharing the same actions * Added some code to make relative KeyingSets (converted from absolute ones) work better.
2009-04-13 11:15:43 +00:00
/* store additional info for relative paths (just in case user makes the set relative) */
if (id)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ksp->idtype = GS(id->name);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* just copy path info */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: should array index be checked too? */
Code cleanup: BLI_strdupn -> BLI_strdup
2014-05-29 02:09:45 +10:00
ksp->rna_path = BLI_strdup(rna_path);
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ksp->array_index = array_index;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* store flags */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ksp->flag = flag;
ksp->groupmode = groupmode;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* add KeyingSet path to KeyingSet */
BLI_addtail(&ks->paths, ksp);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +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;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
}
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +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 the given Keying Set path */
style cleanup: function calls & whitespace.
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 */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, 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;
- use BKE_keyingset_free_path where paths were being freed inline. - rna_path was being freed when null, printing errors.
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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (ksp->rna_path)
- use BKE_keyingset_free_path where paths were being freed inline. - rna_path was being freed when null, printing errors.
2011-01-04 08:56:25 +00:00
MEM_freeN(ksp->rna_path);
== 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);
}
2.5: Screen/Scene New/Delete operators. Implementation Note: * Moved the scene copy/unlink code back into blenkernel, with the exception of the copy single user stuff which is still in object_edit.c. * Uses SCREENDELETE notifier like SCREENBROWSE, seems only clean way to do this now.
2009-08-15 16:43:03 +00:00
/* Copy all KeyingSets in the given list */
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)
2.5: Screen/Scene New/Delete operators. Implementation Note: * Moved the scene copy/unlink code back into blenkernel, with the exception of the copy single user stuff which is still in object_edit.c. * Uses SCREENDELETE notifier like SCREENBROWSE, seems only clean way to do this now.
2009-08-15 16:43:03 +00:00
{
KeyingSet *ksn;
KS_Path *kspn;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Screen/Scene New/Delete operators. Implementation Note: * Moved the scene copy/unlink code back into blenkernel, with the exception of the copy single user stuff which is still in object_edit.c. * Uses SCREENDELETE notifier like SCREENBROWSE, seems only clean way to do this now.
2009-08-15 16:43:03 +00:00
BLI_duplicatelist(newlist, list);
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (ksn = newlist->first; ksn; ksn = ksn->next) {
2.5: Screen/Scene New/Delete operators. Implementation Note: * Moved the scene copy/unlink code back into blenkernel, with the exception of the copy single user stuff which is still in object_edit.c. * Uses SCREENDELETE notifier like SCREENBROWSE, seems only clean way to do this now.
2009-08-15 16:43:03 +00:00
BLI_duplicatelist(&ksn->paths, &ksn->paths);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (kspn = ksn->paths.first; kspn; kspn = kspn->next)
kspn->rna_path = MEM_dupallocN(kspn->rna_path);
2.5: Screen/Scene New/Delete operators. Implementation Note: * Moved the scene copy/unlink code back into blenkernel, with the exception of the copy single user stuff which is still in object_edit.c. * Uses SCREENDELETE notifier like SCREENBROWSE, seems only clean way to do this now.
2009-08-15 16:43:03 +00:00
}
}
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* Freeing Tools --------------------------- */
/* Free data for KeyingSet but not set itself */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_keyingset_free(KeyingSet *ks)
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
{
KS_Path *ksp, *kspn;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* sanity check */
if (ks == NULL)
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* free each path as we go to avoid looping twice */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (ksp = ks->paths.first; ksp; ksp = kspn) {
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);
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
}
}
/* Free all the KeyingSets in the given list */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_keyingsets_free(ListBase *list)
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
{
KeyingSet *ks, *ksn;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* sanity check */
if (list == NULL)
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* loop over KeyingSets freeing them
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - BKE_keyingset_free() doesn't free the set itself, but it frees its sub-data
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (ks = list->first; ks; ks = ksn) {
ksn = ks->next;
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
BKE_keyingset_free(ks);
BLI_freelinkN(list, ks);
}
}
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +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
/* ***************************************** */
/* Evaluation Data-Setting Backend */
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
static bool animsys_store_rna_setting(
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
PointerRNA *ptr,
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
/* typically 'fcu->rna_path', 'fcu->array_index' */
const char *rna_path, const int array_index,
PathResolvedRNA *r_result)
{
bool success = false;
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
const char *path = rna_path;
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
/* write value to setting */
if (path) {
/* get property to write to */
if (RNA_path_resolve_property(ptr, path, &r_result->ptr, &r_result->prop)) {
if ((ptr->id.data == NULL) || RNA_property_animateable(&r_result->ptr, r_result->prop)) {
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) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_WARN(&LOG, "Animato: Invalid array index. ID = '%s', '%s[%d]', array length is %d",
(ptr->id.data) ? (((ID *)ptr->id.data)->name + 2) : "<No ID>",
path, array_index, array_len - 1);
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
}
}
else {
r_result->prop_index = array_len ? array_index : -1;
success = true;
}
}
}
else {
/* 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) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_WARN(&LOG, "Animato: Invalid path. ID = '%s', '%s[%d]'",
(ptr->id.data) ? (((ID *)ptr->id.data)->name + 2) : "<No ID>",
path, array_index);
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
}
}
}
return success;
}
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
Cleanup: typo
2014-11-21 14:14:50 +01:00
/* less than 1.0 evaluates to false, use epsilon to avoid float error */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
#define ANIMSYS_FLOAT_AS_BOOL(value) ((value) > ((1.0f - FLT_EPSILON)))
fcurve/boolean evaluation, values below zero are no longer evaluated to true.
2011-05-26 05:35:30 +00:00
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
2018-04-25 17:46:05 +02:00
static bool animsys_read_rna_setting(PathResolvedRNA *anim_rna, float *r_value)
{
PropertyRNA *prop = anim_rna->prop;
PointerRNA *ptr = &anim_rna->ptr;
int array_index = anim_rna->prop_index;
float orig_value;
/* caller must ensure this is animatable */
BLI_assert(RNA_property_animateable(ptr, prop) || ptr->id.data == NULL);
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);
orig_value = (float)orig_value_coerce;
}
else {
const int orig_value_coerce = RNA_property_boolean_get(ptr, prop);
orig_value = (float)orig_value_coerce;
}
break;
}
case PROP_INT:
{
if (array_index != -1) {
const int orig_value_coerce = RNA_property_int_get_index(ptr, prop, array_index);
orig_value = (float)orig_value_coerce;
}
else {
const int orig_value_coerce = RNA_property_int_get(ptr, prop);
orig_value = (float)orig_value_coerce;
}
break;
}
case PROP_FLOAT:
{
if (array_index != -1) {
const float orig_value_coerce = RNA_property_float_get_index(ptr, prop, array_index);
orig_value = (float)orig_value_coerce;
}
else {
const float orig_value_coerce = RNA_property_float_get(ptr, prop);
orig_value = (float)orig_value_coerce;
}
break;
}
case PROP_ENUM:
{
const int orig_value_coerce = RNA_property_enum_get(ptr, prop);
orig_value = (float)orig_value_coerce;
break;
}
default:
/* nothing can be done here... so it is unsuccessful? */
return false;
}
if (r_value != NULL) {
*r_value = orig_value;
}
/* successful */
return true;
}
Graph Editor - Selection Tools * Mouse-Select and DeSelect All work again * Added access to constraint 'influence' value
2009-01-27 05:04:23 +00:00
/* Write the given value to a setting using RNA, and return success */
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
static bool animsys_write_rna_setting(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
{
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
PropertyRNA *prop = anim_rna->prop;
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
PointerRNA *ptr = &anim_rna->ptr;
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
int array_index = anim_rna->prop_index;
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
2018-04-25 17:46:05 +02:00
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
/* caller must ensure this is animatable */
BLI_assert(RNA_property_animateable(ptr, prop) || ptr->id.data == NULL);
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
2018-04-25 17:46:05 +02:00
/* Check whether value is new. Otherwise we skip all the updates. */
float old_value;
if (!animsys_read_rna_setting(anim_rna, &old_value)) {
return false;
}
if (old_value == value) {
return true;
}
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
switch (RNA_property_type(prop)) {
case PROP_BOOLEAN:
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
{
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
const int value_coerce = ANIMSYS_FLOAT_AS_BOOL(value);
if (array_index != -1) {
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
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
}
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
else {
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
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
}
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
break;
}
case PROP_INT:
{
Fix T50973: Directional blur node doesn't clamp value if using driver The issue was caused by combination of following factors: - Blender Internal viewport render can not distinguish between which parts of main database changed, so it does full database re-sync when anything is tagged for an update. This way, if any NodeTree (including compositor) is changed, Blender Internal viewport is tagged for full render database update. - With old dependency graph, scene-level drivers are evaluated on every iteration of scene_update_tagged, even if nothing is tagged for an update. This causes compositor drivers be evaluated quite often. - Driver evaluation checks whether value was changed, and if so it tags corresponding ID type as updated (this is what was telling viewport to do render database update). This check was quite stupid: current property value was checked against the one coming from driver expression. This means, if driver value is outside of the hard limit range of the property, the property will always be considered updated. The fix is to compare current property value against clamped value from the driver.
2017-07-07 12:08:14 +02:00
int value_coerce = (int)value;
RNA_property_int_clamp(ptr, prop, &value_coerce);
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
if (array_index != -1) {
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
2018-04-25 17:46:05 +02:00
RNA_property_int_set_index(ptr, prop, array_index, value_coerce);
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
}
else {
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
2018-04-25 17:46:05 +02:00
RNA_property_int_set(ptr, prop, value_coerce);
Depsgraph/Python: ensure datablocks with animation data get tagged as being updated on frame change.
2011-11-03 10:03:08 +00:00
}
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
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
}
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
case PROP_FLOAT:
{
Fix T50973: Directional blur node doesn't clamp value if using driver The issue was caused by combination of following factors: - Blender Internal viewport render can not distinguish between which parts of main database changed, so it does full database re-sync when anything is tagged for an update. This way, if any NodeTree (including compositor) is changed, Blender Internal viewport is tagged for full render database update. - With old dependency graph, scene-level drivers are evaluated on every iteration of scene_update_tagged, even if nothing is tagged for an update. This causes compositor drivers be evaluated quite often. - Driver evaluation checks whether value was changed, and if so it tags corresponding ID type as updated (this is what was telling viewport to do render database update). This check was quite stupid: current property value was checked against the one coming from driver expression. This means, if driver value is outside of the hard limit range of the property, the property will always be considered updated. The fix is to compare current property value against clamped value from the driver.
2017-07-07 12:08:14 +02:00
float value_coerce = value;
RNA_property_float_clamp(ptr, prop, &value_coerce);
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
if (array_index != -1) {
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
2018-04-25 17:46:05 +02:00
RNA_property_float_set_index(ptr, prop, array_index, value_coerce);
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
}
else {
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
2018-04-25 17:46:05 +02:00
RNA_property_float_set(ptr, prop, value_coerce);
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
}
break;
}
case PROP_ENUM:
{
const int value_coerce = (int)value;
Animation: Split f-curve reading and writing functions This way we can re-use reading part.
2018-04-25 17:46:05 +02:00
RNA_property_enum_set(ptr, prop, value_coerce);
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
2016-07-30 16:47:18 +10:00
break;
}
default:
/* nothing can be done here... so it is unsuccessful? */
return false;
Graph Editor - Selection Tools * Mouse-Select and DeSelect All work again * Added access to constraint 'influence' value
2009-01-27 05:04:23 +00:00
}
Cleanup: minor changes from last commit Un-indent blocks, rename vars.
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
}
/* Simple replacement based data-setting of the FCurve using RNA */
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
bool BKE_animsys_execute_fcurve(PointerRNA *ptr, FCurve *fcu, float curval)
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
{
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
PathResolvedRNA anim_rna;
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
bool ok = false;
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
if (animsys_store_rna_setting(ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
ok = animsys_write_rna_setting(&anim_rna, curval);
}
Drivers: Errors + UI Tweaks * Invalid drivers are now tagged accordingly and are not evaluated until they are manually refreshed using the 'Update Dependencies' button * Drivers with errors have a error warning shown in their UI * Rearranged the UI buttons a bit for drivers, adding support for a 'remove' driver button.
2009-04-11 06:48:39 +00:00
/* return whether we were successful */
return ok;
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
}
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02:00
static void animsys_write_orig_anim_rna(
PointerRNA *ptr,
NLA: use animsys_write_orig_anim_rna when applying NLA stack results. Without this keyframing on top of an NLA stack is quite weirdly broken.
2018-11-07 19:47:22 +03:00
const char *rna_path,
int array_index,
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
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
{
Fix T57360: Crash when Play Animation in this scene Was caused by a code which was putting animation value back to original datablock. The tricky part here is that we don't always know ID, so can not put those values. Would be nice to have a solution for this, but for until then we should be relatively good.
2018-10-29 11:06:53 +01:00
/* Pointer is expected to be an ID pointer, if it's not -- we are doomed.
*
* NOTE: It is possible to have animation data on NLA strip, see T57360.
* TODO(sergey): Find solution for those cases.
*/
if (ptr->id.data == NULL) {
return;
}
Animation: Make it possible to keyframe to with copy-on-write The issue was that every object tweak was doing a full copy of original datablock onto evaluated version, and was updating animation. This made it impossible to tweak properties which has keyframes. Proposed solution is to: - Always apply animation on frame change, and when object is explicitly tagged for animation update. This will store original DNA value of animated property in the f-curve. - When applying animation in other cases, we check original DNA value stored in f-curve with the actual original DNA property. If they differ, it means user started to tweak animated property, and we should skip animation. If the value is the same, we apply animation. This is just a first step towards proper final implementation, but seems to be the direction we want to take.
2018-04-25 17:59:08 +02:00
PointerRNA orig_ptr = *ptr;
Cleanup: style, duplicate includes
2018-04-28 09:01:34 +02:00
orig_ptr.id.data = ((ID *)orig_ptr.id.data)->orig_id;
Animation: Make it possible to keyframe to with copy-on-write The issue was that every object tweak was doing a full copy of original datablock onto evaluated version, and was updating animation. This made it impossible to tweak properties which has keyframes. Proposed solution is to: - Always apply animation on frame change, and when object is explicitly tagged for animation update. This will store original DNA value of animated property in the f-curve. - When applying animation in other cases, we check original DNA value stored in f-curve with the actual original DNA property. If they differ, it means user started to tweak animated property, and we should skip animation. If the value is the same, we apply animation. This is just a first step towards proper final implementation, but seems to be the direction we want to take.
2018-04-25 17:59:08 +02:00
orig_ptr.data = orig_ptr.id.data;
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02:00
PathResolvedRNA orig_anim_rna;
/* TODO(sergey): Is there a faster way to get anim_rna of original ID? */
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
if (animsys_store_rna_setting(&orig_ptr, rna_path, array_index, &orig_anim_rna)) {
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02:00
animsys_write_rna_setting(&orig_anim_rna, value);
}
}
Animation: Make it possible to keyframe to with copy-on-write The issue was that every object tweak was doing a full copy of original datablock onto evaluated version, and was updating animation. This made it impossible to tweak properties which has keyframes. Proposed solution is to: - Always apply animation on frame change, and when object is explicitly tagged for animation update. This will store original DNA value of animated property in the f-curve. - When applying animation in other cases, we check original DNA value stored in f-curve with the actual original DNA property. If they differ, it means user started to tweak animated property, and we should skip animation. If the value is the same, we apply animation. This is just a first step towards proper final implementation, but seems to be the direction we want to take.
2018-04-25 17:59:08 +02:00
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02: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
*/
static void animsys_evaluate_fcurves(
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
Depsgraph *depsgraph, PointerRNA *ptr, ListBase *list, float ctime)
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02:00
{
const bool is_active_depsgraph = DEG_is_active(depsgraph);
Cleanup: Reduce indentation level
2018-05-31 11:09:48 +02:00
/* Calculate then execute each curve. */
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02:00
for (FCurve *fcu = list->first; fcu; fcu = fcu->next) {
Cleanup: Reduce indentation level
2018-05-31 11:09:48 +02:00
/* Check if this F-Curve doesn't belong to a muted group. */
if ((fcu->grp != NULL) && (fcu->grp->flag & AGRP_MUTED)) {
continue;
}
/* Check if this curve should be skipped. */
if ((fcu->flag & (FCURVE_MUTED | FCURVE_DISABLED))) {
continue;
}
PathResolvedRNA anim_rna;
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
if (animsys_store_rna_setting(ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
Cleanup: Reduce indentation level
2018-05-31 11:09:48 +02:00
const float curval = calculate_fcurve(&anim_rna, fcu, ctime);
animsys_write_rna_setting(&anim_rna, curval);
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02:00
if (is_active_depsgraph) {
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
animsys_write_orig_anim_rna(ptr, fcu->rna_path, fcu->array_index, curval);
NLA SoC: Muting and Graph-Editor Curve visibility for (Action) Groups Groups (the Action variety) can now be muted, and also be set to not be drawn in the Graph Editor. These settings get applied to all the F-Curves within the group, overriding any settings individual F-Curves might have, allowing users to quickly mute or hide groups of curves without having to go through clicking on all of them. Also, added a flag that can be used to set the curve visiblity on AnimData level too. This will be enabled in a future commit.
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
}
}
}
/* ***************************************** */
/* Driver Evaluation */
/* Evaluate Drivers */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void animsys_evaluate_drivers(PointerRNA *ptr, AnimData *adt, 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
{
FCurve *fcu;
Cleanup: trailing space for blenkernel
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
/* 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...
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (fcu = adt->drivers.first; fcu; fcu = fcu->next) {
ChannelDriver *driver = fcu->driver;
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
bool ok = false;
Cleanup: trailing space for blenkernel
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
/* check if this driver's curve should be skipped */
style cleanup: whitespace
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 */
Few minors style and type fixes (and a nice, harmless copy/paste error! ;) )
2012-06-12 08:32:06 +00:00
/* XXX driver recalc flag is not set yet by depsgraph! */
Fix T59495, T59992, T59904, T59178, T60598: broken keyframed value editing. This removes a bunch of animation/driver evaluations and recalc flags that should be redundant in the new depsgraph, and were incorrectly affecting the evaluated scene in a permanent way. Still two cases that could be removed if the depsgraph is improved, in BKE_object_handle_data_update and BKE_cachefile_update_frame. For physics subframe interpolation there are also still calls to BKE_object_where_is_calc that should ideally be removed as well, though they are not known to cause keyframing bugs. Differential Revision: https://developer.blender.org/D4274
2019-01-29 11:59:17 +01:00
if ((driver) && !(driver->flag & DRIVER_FLAG_INVALID)) {
Few minors style and type fixes (and a nice, harmless copy/paste error! ;) )
2012-06-12 08:32:06 +00:00
/* evaluate this using values set already in other places
* 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 */
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
PathResolvedRNA anim_rna;
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
if (animsys_store_rna_setting(ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
const float curval = calculate_fcurve(&anim_rna, fcu, ctime);
ok = animsys_write_rna_setting(&anim_rna, curval);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers: Errors + UI Tweaks * Invalid drivers are now tagged accordingly and are not evaluated until they are manually refreshed using the 'Update Dependencies' button * Drivers with errors have a error warning shown in their UI * Rearranged the UI buttons a bit for drivers, adding support for a 'remove' driver button.
2009-04-11 06:48:39 +00:00
/* set error-flag if evaluation failed */
if (ok == 0)
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
driver->flag |= DRIVER_FLAG_INVALID;
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 */
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
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
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void action_idcode_patch_check(ID *id, bAction *act)
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
{
int idcode = 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
/* just in case */
if (ELEM(NULL, id, act))
return;
else
idcode = GS(id->name);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
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) {
/* use the current root if not set already (i.e. newly created actions and actions from 2.50-2.57 builds)
Cleanup: comment block tabs
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 (?)
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
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) */
move debug flag into its own global var (G.debug), split up debug options. --debug --debug-ffmpeg --debug-python --debug-events --debug-wm This makes debug output easier to read - event debug prints would flood output too much before. For convenience: --debug-all turns all debug flags on (works as --debug did before). also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
2012-03-31 00:59:17 +00:00
if (G.debug & G_DEBUG) {
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
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",
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
act->id.name + 2, idcode, id->name);
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
}
}
}
/* ----------------------------------------- */
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
/* Evaluate Action Group */
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
void animsys_evaluate_action_group(PointerRNA *ptr, bAction *act, bActionGroup *agrp, float ctime)
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
{
FCurve *fcu;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
/* check if mapper is appropriate for use here (we set to NULL if it's inappropriate) */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, act, agrp)) return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
action_idcode_patch_check(ptr->id.data, act);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Muting and Graph-Editor Curve visibility for (Action) Groups Groups (the Action variety) can now be muted, and also be set to not be drawn in the Graph Editor. These settings get applied to all the F-Curves within the group, overriding any settings individual F-Curves might have, allowing users to quickly mute or hide groups of curves without having to go through clicking on all of them. Also, added a flag that can be used to set the curve visiblity on AnimData level too. This will be enabled in a future commit.
2009-07-03 10:28:10 +00:00
/* if group is muted, don't evaluated any of the F-Curve */
if (agrp->flag & AGRP_MUTED)
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
/* calculate then execute each curve */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (fcu = agrp->channels.first; (fcu) && (fcu->grp == agrp); fcu = fcu->next) {
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
/* check if this curve should be skipped */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ((fcu->flag & (FCURVE_MUTED | FCURVE_DISABLED)) == 0) {
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
PathResolvedRNA anim_rna;
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
if (animsys_store_rna_setting(ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
const float curval = calculate_fcurve(&anim_rna, fcu, ctime);
animsys_write_rna_setting(&anim_rna, curval);
}
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +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
/* Evaluate Action (F-Curve Bag) */
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
static void animsys_evaluate_action_ex(
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
Depsgraph *depsgraph, PointerRNA *ptr, bAction *act, 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
{
/* check if mapper is appropriate for use here (we set to NULL if it's inappropriate) */
if (act == NULL) return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
action_idcode_patch_check(ptr->id.data, act);
Cleanup: trailing space for blenkernel
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 */
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
animsys_evaluate_fcurves(depsgraph, ptr, &act->curves, ctime);
Animation: Make it possible to keyframe to with copy-on-write The issue was that every object tweak was doing a full copy of original datablock onto evaluated version, and was updating animation. This made it impossible to tweak properties which has keyframes. Proposed solution is to: - Always apply animation on frame change, and when object is explicitly tagged for animation update. This will store original DNA value of animated property in the f-curve. - When applying animation in other cases, we check original DNA value stored in f-curve with the actual original DNA property. If they differ, it means user started to tweak animated property, and we should skip animation. If the value is the same, we apply animation. This is just a first step towards proper final implementation, but seems to be the direction we want to take.
2018-04-25 17:59:08 +02:00
}
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
void animsys_evaluate_action(Depsgraph *depsgraph, PointerRNA *ptr, bAction *act, float ctime)
Animation: Make it possible to keyframe to with copy-on-write The issue was that every object tweak was doing a full copy of original datablock onto evaluated version, and was updating animation. This made it impossible to tweak properties which has keyframes. Proposed solution is to: - Always apply animation on frame change, and when object is explicitly tagged for animation update. This will store original DNA value of animated property in the f-curve. - When applying animation in other cases, we check original DNA value stored in f-curve with the actual original DNA property. If they differ, it means user started to tweak animated property, and we should skip animation. If the value is the same, we apply animation. This is just a first step towards proper final implementation, but seems to be the direction we want to take.
2018-04-25 17:59:08 +02:00
{
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
animsys_evaluate_action_ex(depsgraph, ptr, act, 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
}
/* ***************************************** */
/* NLA System - Evaluation */
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* calculate influence of strip based for given frame based on blendin/out values */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static float nlastrip_get_influence(NlaStrip *strip, float cframe)
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
{
style cleanup - comment spelling + translate some dutch.
2012-03-04 04:35:12 +00:00
/* sanity checks - normalize the blendin/out values? */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
strip->blendin = fabsf(strip->blendin);
strip->blendout = fabsf(strip->blendout);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* result depends on where frame is in respect to blendin/out values */
replace IS_EQ -> IS_EQF for use with floats.
2013-11-10 12:56:50 +00:00
if (IS_EQF(strip->blendin, 0.0f) == false && (cframe <= (strip->start + strip->blendin))) {
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* there is some blend-in */
replace fabs with fabsf where both input and output are floats.
2011-11-19 01:10:05 +00:00
return fabsf(cframe - strip->start) / (strip->blendin);
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
}
replace IS_EQ -> IS_EQF for use with floats.
2013-11-10 12:56:50 +00:00
else if (IS_EQF(strip->blendout, 0.0f) == false && (cframe >= (strip->end - strip->blendout))) {
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* there is some blend-out */
replace fabs with fabsf where both input and output are floats.
2011-11-19 01:10:05 +00:00
return fabsf(strip->end - cframe) / (strip->blendout);
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
}
else {
/* in the middle of the strip, we should be full strength */
return 1.0f;
}
}
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 SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* evaluate the evaluation time and influence for the strip, storing the results in the strip */
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
static void nlastrip_evaluate_controls(Depsgraph *depsgraph, NlaStrip *strip, float ctime)
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
{
/* now strip's evaluate F-Curves for these settings (if applicable) */
if (strip->fcurves.first) {
PointerRNA strip_ptr;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* create RNA-pointer needed to set values */
RNA_pointer_create(NULL, &RNA_NlaStrip, strip, &strip_ptr);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* execute these settings as per normal */
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
animsys_evaluate_fcurves(depsgraph, &strip_ptr, &strip->fcurves, ctime);
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix for earlier commit - Turning off "animated" influence/time didn't work Reshuffled order that in which NLA Strip's F-Curves vs its automatic settings are evaluated so that the automatic settings can always override the custom settings, since it's not that easy to get things working correctly the other way around.
2015-03-13 19:05:27 +13:00
/* analytically generate values for influence and time (if applicable)
Cleanup: comment block tabs
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.
Fix for earlier commit - Turning off "animated" influence/time didn't work Reshuffled order that in which NLA Strip's F-Curves vs its automatic settings are evaluated so that the automatic settings can always override the custom settings, since it's not that easy to get things working correctly the other way around.
2015-03-13 19:05:27 +13:00
*/
if ((strip->flag & NLASTRIP_FLAG_USR_INFLUENCE) == 0)
strip->influence = nlastrip_get_influence(strip, ctime);
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
NLA: ignore time range when evaluating a raw action. When editing an action without a strip, or tweaking a strip without time mapping enabled or supported, the extents of the virtual strip can't be controlled and are purely derived from keys in the action. Thus, cutting off evaluation of the action at these arbitrary points gets in the way of observing the natural extrapolation of the F-Curves and thus appears to be a mis-feature. With this change non-mapped actions are evaluated with infinite range, exactly like they are handled without NLA, unless extend mode is set to Nothing.
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) {
strip->strip_time = ctime;
return;
}
if ((strip->flag & NLASTRIP_FLAG_USR_TIME) == 0)
strip->strip_time = nlastrip_get_frame(strip, ctime, NLATIME_CONVERT_EVAL);
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* if user can control the evaluation time (using F-Curves), consider the option which allows this time to be clamped
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
* 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
*/
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* NOTE: if we add any more of these special cases, we better group them up nicely... */
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
if ((strip->flag & NLASTRIP_FLAG_USR_TIME) && (strip->flag & NLASTRIP_FLAG_USR_TIME_CYCLIC))
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
strip->strip_time = fmod(strip->strip_time - strip->actstart, strip->actend - strip->actstart);
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
}
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
/* gets the strip active at the current time for a list of strips for evaluation purposes */
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
NlaEvalStrip *nlastrips_ctime_get_strip(Depsgraph *depsgraph, ListBase *list, ListBase *strips, short index, 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
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
NlaStrip *strip, *estrip = NULL;
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
NlaEvalStrip *nes;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
short side = 0;
Cleanup: trailing space for blenkernel
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
/* loop over strips, checking if they fall within the range */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (strip = strips->first; strip; strip = strip->next) {
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* check if current time occurs within this strip */
NLA: ignore time range when evaluating a raw action. When editing an action without a strip, or tweaking a strip without time mapping enabled or supported, the extents of the virtual strip can't be controlled and are purely derived from keys in the action. Thus, cutting off evaluation of the action at these arbitrary points gets in the way of observing the natural extrapolation of the F-Curves and thus appears to be a mis-feature. With this change non-mapped actions are evaluated with infinite range, exactly like they are handled without NLA, unless extend mode is set to Nothing.
2019-01-12 14:10:09 +03:00
if (IN_RANGE_INCL(ctime, strip->start, strip->end) || (strip->flag & NLASTRIP_FLAG_NO_TIME_MAP)) {
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* this strip is active, so try to use it */
style cleanup: whitespace
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;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* if time occurred before current strip... */
if (ctime < strip->start) {
NLA SoC: Start of 'Meta' Strips Refactored the backend code/API's to support 'meta' strips (i.e. strips containing other strips). These have been implemented to be nested to 'unlimited' depths (in terms of common usages that is, though there is a very remote chance of stack-overflow in theoretrical evil cases only that shouldn't ever be encountered in production). This paves the way for implementing the necessary tweaks needed for the transform code (in addition to some cool user-level tricks)
2009-07-06 03:44:44 +00:00
if (strip == strips->first) {
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* before first strip - only try to use it if it extends backwards in time too */
if (strip->extendmode == NLASTRIP_EXTEND_HOLD)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
estrip = strip;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* side is 'before' regardless of whether there's a useful strip */
style cleanup: whitespace
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 {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* before next strip - previous strip has ended, but next hasn't begun,
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
* so blending mode depends on whether strip is being held or not...
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - only occurs when no transition strip added, otherwise the transition would have
* been picked up above...
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
strip = strip->prev;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
if (strip->extendmode != NLASTRIP_EXTEND_NOTHING)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
estrip = strip;
side = NES_TIME_AFTER;
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
}
break;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
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 */
NLA SoC: Start of 'Meta' Strips Refactored the backend code/API's to support 'meta' strips (i.e. strips containing other strips). These have been implemented to be nested to 'unlimited' depths (in terms of common usages that is, though there is a very remote chance of stack-overflow in theoretrical evil cases only that shouldn't ever be encountered in production). This paves the way for implementing the necessary tweaks needed for the transform code (in addition to some cool user-level tricks)
2009-07-06 03:44:44 +00:00
if (strip == strips->last) {
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
if (strip->extendmode != NLASTRIP_EXTEND_NOTHING)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
estrip = strip;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
side = NES_TIME_AFTER;
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
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
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
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
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* check if a valid strip was found
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - must not be muted (i.e. will have contribution
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
*/
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
if ((estrip == NULL) || (estrip->flag & NLASTRIP_FLAG_MUTED))
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: 2 little tweaks - Evaluation times for strips are now strictly clamped to the endpoints of the strips - i.e. if a strip has 'extend' on, the strip's evaluation time won't continue to change as time changes - New NLA Editor instances now have auto-snapping turned on by default (as they should)
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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ctime = estrip->start;
NLA SoC: 2 little tweaks - Evaluation times for strips are now strictly clamped to the endpoints of the strips - i.e. if a strip has 'extend' on, the strip's evaluation time won't continue to change as time changes - New NLA Editor instances now have auto-snapping turned on by default (as they should)
2009-06-07 07:04:31 +00:00
break;
case NES_TIME_AFTER: /* extend last frame only */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ctime = estrip->end;
NLA SoC: 2 little tweaks - Evaluation times for strips are now strictly clamped to the endpoints of the strips - i.e. if a strip has 'extend' on, the strip's evaluation time won't continue to change as time changes - New NLA Editor instances now have auto-snapping turned on by default (as they should)
2009-06-07 07:04:31 +00:00
break;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* evaluate strip's evaluation controls
Cleanup: comment block tabs
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?
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
*/
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: this sounds a bit hacky having a few isolated F-Curves stuck on some data it operates on... */
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
nlastrip_evaluate_controls(depsgraph, estrip, ctime);
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
if (estrip->influence <= 0.0f)
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
/* check if strip has valid data to evaluate,
* and/or perform any additional type-specific actions
*/
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
switch (estrip->type) {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
case NLASTRIP_TYPE_CLIP:
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* clip must have some action to evaluate */
if (estrip->act == NULL)
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
return NULL;
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
break;
case NLASTRIP_TYPE_TRANSITION:
/* there must be strips to transition from and to (i.e. prev and next required) */
if (ELEM(NULL, estrip->prev, estrip->next))
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
/* evaluate controls for the relevant extents of the bordering strips... */
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
nlastrip_evaluate_controls(depsgraph, estrip->prev, estrip->start);
nlastrip_evaluate_controls(depsgraph, estrip->next, estrip->end);
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
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
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Initial commit of changes for the way NLA is evaluated * Recoded the flags for NLA-Strips to take into account the new design directions * Modified parts of the evaluation pipeline to reflect this
2009-05-03 11:46:57 +00:00
/* add to list of strips we need to evaluate */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
nes = MEM_callocN(sizeof(NlaEvalStrip), "NlaEvalStrip");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: whitespace
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;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
if (list)
BLI_addtail(list, nes);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
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
}
/* ---------------------- */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* Initialize a valid mask, allocating memory if necessary. */
static void nlavalidmask_init(NlaValidMask *mask, int bits)
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
{
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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;
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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);
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* ---------------------- */
/* Hashing functions for NlaEvalChannelKey. */
static uint nlaevalchan_keyhash(const void *ptr)
{
const NlaEvalChannelKey *key = ptr;
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)
{
const NlaEvalChannelKey *A = a;
const NlaEvalChannelKey *B = b;
Cleanup: avoid function call for pointer compare
2019-01-05 19:55:25 +11:00
return ((A->ptr.data != B->ptr.data) ||
(A->prop != B->prop));
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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;
NlaEvalChannelSnapshot *nec_snapshot = MEM_callocN(byte_size, "NlaEvalChannelSnapshot");
nec_snapshot->channel = nec;
nec_snapshot->length = length;
return nec_snapshot;
}
/* Free a channel's blending value snapshot. */
static void nlaevalchan_snapshot_free(NlaEvalChannelSnapshot *nec_snapshot)
{
BLI_assert(!nec_snapshot->is_base);
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;
snapshot->size = MAX2(16, nlaeval->num_channels);
snapshot->channels = MEM_callocN(sizeof(*snapshot->channels) * snapshot->size, "NlaEvalSnapshot::channels");
}
/* Retrieve the individual channel snapshot. */
static NlaEvalChannelSnapshot *nlaeval_snapshot_get(NlaEvalSnapshot *snapshot, int index)
{
return (index < snapshot->size) ? snapshot->channels[index] : NULL;
}
/* 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;
snapshot->channels = MEM_recallocN_id(snapshot->channels, byte_size, "NlaEvalSnapshot::channels");
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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];
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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)
Bugfix [#35856] Bones gets scaled chaotically when during NLA Strip Blend In/Out This was one of the consequences of r.57333 (i.e. influence shouldn't be ignored on the first strip that animates a channel), as scale should really default to a base value of 1 (instead of things being blended against 0 as per all other properties). The end result was that bones were getting scaled to zero here when the influence of their strip fell to zero. Now, we use the RNA default values of properties to initialise their initial values. This may/may not work well in all cases: 1) For properties which don't have the appropriate RNA defaults set, this will be problematic. But, most properties people are likely to animate here I think are already set up correctly. 2) It may not always be nice to have values "snapping back" to default values. In this case, you should still be defining a strip at the bottom of your NLA stack which defines what the appropriate rest poses *should* be for your shot.
2013-07-01 13:57:00 +00:00
{
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
while (snapshot != NULL) {
NlaEvalChannelSnapshot *nec_snapshot = nlaeval_snapshot_get(snapshot, nec->index);
if (nec_snapshot != NULL) {
return nec_snapshot;
}
snapshot = snapshot->base;
}
return &nec->base_snapshot;
}
/* Retrieve or create the channel value snapshot, copying from the other snapshot (or default values) */
static NlaEvalChannelSnapshot *nlaeval_snapshot_ensure_channel(NlaEvalSnapshot *snapshot, NlaEvalChannel *nec)
{
NlaEvalChannelSnapshot **slot = nlaeval_snapshot_ensure_slot(snapshot, nec);
if (*slot == NULL) {
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)
{
if (snapshot->channels != NULL) {
for (int i = 0; i < snapshot->size; i++) {
NlaEvalChannelSnapshot *nec_snapshot = snapshot->channels[i];
if (nec_snapshot != NULL) {
nlaevalchan_snapshot_free(nec_snapshot);
}
}
MEM_freeN(snapshot->channels);
}
snapshot->base = NULL;
snapshot->size = 0;
snapshot->channels = NULL;
}
/* ---------------------- */
/* Free memory owned by this evaluation channel. */
static void nlaevalchan_free_data(NlaEvalChannel *nec)
{
nlavalidmask_free(&nec->valid);
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
if (nec->blend_snapshot != NULL) {
nlaevalchan_snapshot_free(nec->blend_snapshot);
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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. */
for (NlaEvalChannel *nec = nlaeval->channels.first; nec; nec = nec->next) {
nlaevalchan_free_data(nec);
}
BLI_freelistN(&nlaeval->channels);
BLI_ghash_free(nlaeval->path_hash, NULL, NULL);
BLI_ghash_free(nlaeval->key_hash, NULL, NULL);
}
/* ---------------------- */
static int nlaevalchan_validate_index(NlaEvalChannel *nec, int index)
{
if (nec->is_array) {
if (index >= 0 && index < nec->base_snapshot.length) {
return index;
}
return -1;
}
else {
return 0;
}
}
/* Initialise default values for NlaEvalChannel from the property data. */
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;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
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;
}
Cleanup: trailing space for blenkernel
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
Bugfix [#35856] Bones gets scaled chaotically when during NLA Strip Blend In/Out This was one of the consequences of r.57333 (i.e. influence shouldn't be ignored on the first strip that animates a channel), as scale should really default to a base value of 1 (instead of things being blended against 0 as per all other properties). The end result was that bones were getting scaled to zero here when the influence of their strip fell to zero. Now, we use the RNA default values of properties to initialise their initial values. This may/may not work well in all cases: 1) For properties which don't have the appropriate RNA defaults set, this will be problematic. But, most properties people are likely to animate here I think are already set up correctly. 2) It may not always be nice to have values "snapping back" to default values. In this case, you should still be defining a strip at the bottom of your NLA stack which defines what the appropriate rest poses *should* be for your shot.
2013-07-01 13:57:00 +00:00
* in NLA strips a lot, e.g. scale) are set correctly.
*/
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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;
switch (RNA_property_type(prop)) {
case PROP_BOOLEAN:
tmp_bool = MEM_malloc_arrayN(sizeof(*tmp_bool), length, __func__);
RNA_property_boolean_get_default_array(ptr, prop, tmp_bool);
for (int i = 0; i < length; i++) {
r_values[i] = (float)tmp_bool[i];
}
MEM_freeN(tmp_bool);
break;
case PROP_INT:
tmp_int = MEM_malloc_arrayN(sizeof(*tmp_int), length, __func__);
RNA_property_int_get_default_array(ptr, prop, tmp_int);
for (int i = 0; i < length; i++) {
r_values[i] = (float)tmp_int[i];
}
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);
switch (RNA_property_type(prop)) {
case PROP_BOOLEAN:
*r_values = (float)RNA_property_boolean_get_default(ptr, prop);
break;
case PROP_INT:
*r_values = (float)RNA_property_int_get_default(ptr, prop);
break;
case PROP_FLOAT:
*r_values = RNA_property_float_get_default(ptr, prop);
break;
case PROP_ENUM:
*r_values = (float)RNA_property_enum_get_default(ptr, prop);
break;
default:
*r_values = 0.0f;
}
Bugfix [#35856] Bones gets scaled chaotically when during NLA Strip Blend In/Out This was one of the consequences of r.57333 (i.e. influence shouldn't be ignored on the first strip that animates a channel), as scale should really default to a base value of 1 (instead of things being blended against 0 as per all other properties). The end result was that bones were getting scaled to zero here when the influence of their strip fell to zero. Now, we use the RNA default values of properties to initialise their initial values. This may/may not work well in all cases: 1) For properties which don't have the appropriate RNA defaults set, this will be problematic. But, most properties people are likely to animate here I think are already set up correctly. 2) It may not always be nice to have values "snapping back" to default values. In this case, you should still be defining a strip at the bottom of your NLA stack which defines what the appropriate rest poses *should* be for your shot.
2013-07-01 13:57:00 +00:00
}
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
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;
}
else if (subtype == PROP_AXISANGLE && length == 4) {
return NEC_MIX_AXIS_ANGLE;
}
else if (RNA_property_flag(key->prop) & PROP_PROPORTIONAL) {
return NEC_MIX_MULTIPLY;
}
else {
return NEC_MIX_ADD;
}
Bugfix [#35856] Bones gets scaled chaotically when during NLA Strip Blend In/Out This was one of the consequences of r.57333 (i.e. influence shouldn't be ignored on the first strip that animates a channel), as scale should really default to a base value of 1 (instead of things being blended against 0 as per all other properties). The end result was that bones were getting scaled to zero here when the influence of their strip fell to zero. Now, we use the RNA default values of properties to initialise their initial values. This may/may not work well in all cases: 1) For properties which don't have the appropriate RNA defaults set, this will be problematic. But, most properties people are likely to animate here I think are already set up correctly. 2) It may not always be nice to have values "snapping back" to default values. In this case, you should still be defining a strip at the bottom of your NLA stack which defines what the appropriate rest poses *should* be for your shot.
2013-07-01 13:57:00 +00:00
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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)
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
{
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* Look it up in the key hash. */
NlaEvalChannel **p_key_nec;
NlaEvalChannelKey **p_key;
Cleanup: style, line length
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);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
if (found_key) {
return *p_key_nec;
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaEvalChannel *nec = MEM_callocN(sizeof(NlaEvalChannel) + sizeof(float) * length, "NlaEvalChannel");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* Initialize the channel. */
nec->rna_path = path;
nec->key = *key;
NLA: use animsys_write_orig_anim_rna when applying NLA stack results. Without this keyframing on top of an NLA stack is quite weirdly broken.
2018-11-07 19:47:22 +03:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nec->owner = nlaeval;
nec->index = nlaeval->num_channels++;
nec->is_array = is_array;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
nec->mix_mode = nlaevalchan_detect_mix_mode(key, length);
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlavalidmask_init(&nec->valid, length);
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;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
return nec;
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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)
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
{
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
if (path == NULL) {
return NULL;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* Lookup the path in the path based hash. */
NlaEvalChannel **p_path_nec;
Cleanup: style, line length
2019-01-06 20:26:08 +11:00
bool found_path = BLI_ghash_ensure_p(nlaeval->path_hash, (void *)path, (void ***)&p_path_nec);
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
if (found_path) {
return *p_path_nec;
Fix T36496: unwanted behavior with NLA strip blend mode Replace. If you have two overlapping NLA strips it automatically blends between them. However it was also blending between the first strip and the rest pose (e.g. 0,0,0 for locations and 1,1,1 for scale). This is ok if the blend mode is Add or Multiply since then you are adding onto the rest pose, but for Replace you want to be able to mix between two poses and not take the rest pose into account at all. What this does is that to not do any blending for the first strip if it has blend mode Replace. If someone wants the old behavior (from bugfix commit 27d792fa9ca1) they can still make an action with the rest pose and use that as the first strip.
2014-03-03 16:34:10 +01:00
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_WARN(&LOG, "Animato: Invalid path. ID = '%s', '%s'",
(ptr->id.data) ? (((ID *)ptr->id.data)->name + 2) : "<No ID>", path);
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
}
/* Cache NULL result. */
*p_path_nec = NULL;
return NULL;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaEvalChannel *nec = nlaevalchan_verify_key(nlaeval, path, &key);
if (nec->rna_path == NULL) {
nec->rna_path = path;
}
return *p_path_nec = nec;
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* ---------------------- */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
/* accumulate the old and new values of a channel according to mode and influence */
static float nla_blend_value(int blendmode, float old_value, float value, float inf)
{
Bugfix [#35382] NLA "Multiply" Blend Mode calculated incorrectly The "Multiply" blending mode for NLA strips worked incorrectly. Instead of modulating the influence of the current strip, it was in fact scaling the result of the entire stack (with the strip applied). This caused problems when influence = 0, as it was in fact muting everything instead of just controlling the strip we are interested in.
2013-06-10 11:58:57 +00:00
/* optimisation: no need to try applying if there is no influence */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
if (IS_EQF(inf, 0.0f)) {
return old_value;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
/* perform blending */
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
switch (blendmode) {
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
case NLASTRIP_MODE_ADD:
/* simply add the scaled value on to the stack */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
return old_value + (value * inf);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
case NLASTRIP_MODE_SUBTRACT:
/* simply subtract the scaled value from the stack */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
return old_value - (value * inf);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
case NLASTRIP_MODE_MULTIPLY:
/* multiply the scaled value with the stack */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Formula Used:
* result = fac * (a * b) + (1 - fac) * a
Bugfix [#35382] NLA "Multiply" Blend Mode calculated incorrectly The "Multiply" blending mode for NLA strips worked incorrectly. Instead of modulating the influence of the current strip, it was in fact scaling the result of the entire stack (with the strip applied). This caused problems when influence = 0, as it was in fact muting everything instead of just controlling the strip we are interested in.
2013-06-10 11:58:57 +00:00
*/
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
return inf * (old_value * value) + (1 - inf) * old_value;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
case NLASTRIP_MODE_COMBINE:
BLI_assert(!"combine mode");
ATTR_FALLTHROUGH;
NLA SoC: Tweaks from feedback from Broken + jez * Renamed the 'blend' blending mode to 'replace', since that's what it usually does * Drawing a darkened rect behind the keyframes shown in the action line -- * Fixed typo made last night which broke compiling * Consolidated all the keyframe-shape drawing code to use a single codebase. Even if we don't ultimately go with OpenGL keyframes, there's always a tidy option for that now.
2009-07-10 00:32:13 +00:00
case NLASTRIP_MODE_REPLACE:
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
default: /* TODO: do we really want to blend by default? it seems more uses might prefer add... */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* do linear interpolation
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - the influence of the accumulated data (elsewhere, that is called dstweight)
* is 1 - influence, since the strip's influence is srcweight
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
*/
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
return old_value * (1.0f - inf) + (value * inf);
}
}
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
/* accumulate the old and new values of a channel according to mode and influence */
static float nla_combine_value(int mix_mode, float base_value, float old_value, float value, float inf)
{
/* optimisation: no need to try applying if there is no influence */
if (IS_EQF(inf, 0.0f)) {
return old_value;
}
/* perform blending */
switch (mix_mode) {
case NEC_MIX_ADD:
case NEC_MIX_AXIS_ANGLE:
return old_value + (value - base_value) * inf;
case NEC_MIX_MULTIPLY:
if (base_value == 0.0f) {
base_value = 1.0f;
}
return old_value * powf(value / base_value, inf);
case NEC_MIX_QUATERNION:
default:
BLI_assert(!"invalid mix mode");
return old_value;
}
}
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
/* compute the value that would blend to the desired target value using nla_blend_value */
static bool nla_invert_blend_value(int blend_mode, float old_value, float target_value, float influence, float *r_value)
{
switch (blend_mode) {
case NLASTRIP_MODE_ADD:
*r_value = (target_value - old_value) / influence;
return true;
case NLASTRIP_MODE_SUBTRACT:
*r_value = (old_value - target_value) / influence;
return true;
case NLASTRIP_MODE_MULTIPLY:
if (old_value == 0.0f) {
/* Resolve 0/0 to 1. */
if (target_value == 0.0f) {
*r_value = 1.0f;
return true;
}
/* Division by zero. */
return false;
}
else {
*r_value = (target_value - old_value) / influence / old_value + 1.0f;
return true;
}
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
case NLASTRIP_MODE_COMBINE:
BLI_assert(!"combine mode");
ATTR_FALLTHROUGH;
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
case NLASTRIP_MODE_REPLACE:
default:
*r_value = (target_value - old_value) / influence + old_value;
return true;
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
}
}
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
/* compute the value that would blend to the desired target value using nla_combine_value */
static bool nla_invert_combine_value(int mix_mode, float base_value, float old_value, float target_value, float influence, float *r_value)
{
switch (mix_mode) {
case NEC_MIX_ADD:
case NEC_MIX_AXIS_ANGLE:
*r_value = base_value + (target_value - old_value) / influence;
return true;
case NEC_MIX_MULTIPLY:
if (base_value == 0.0f) {
base_value = 1.0f;
}
if (old_value == 0.0f) {
/* Resolve 0/0 to 1. */
if (target_value == 0.0f) {
*r_value = base_value;
return true;
}
/* Division by zero. */
return false;
}
else {
*r_value = base_value * powf(target_value / old_value, 1.0f / influence);
return true;
}
case NEC_MIX_QUATERNION:
default:
BLI_assert(!"invalid mix mode");
return false;
}
}
/* accumulate quaternion channels for Combine mode according to influence */
static void nla_combine_quaternion(const float old_values[4], const float values[4], float influence, float result[4])
{
float tmp_old[4], tmp_new[4];
normalize_qt_qt(tmp_old, old_values);
normalize_qt_qt(tmp_new, values);
pow_qt_fl_normalized(tmp_new, influence);
mul_qt_qtqt(result, tmp_old, tmp_new);
}
/* invert accumulation of quaternion channels for Combine mode according to influence */
static void nla_invert_combine_quaternion(const float old_values[4], const float values[4], float influence, float result[4])
{
float tmp_old[4], tmp_new[4];
normalize_qt_qt(tmp_old, old_values);
normalize_qt_qt(tmp_new, values);
invert_qt_normalized(tmp_old);
mul_qt_qtqt(result, tmp_old, tmp_new);
pow_qt_fl_normalized(result, 1.0f / influence);
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* Data about the current blend mode. */
typedef struct NlaBlendData {
NlaEvalSnapshot *snapshot;
int mode;
float influence;
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
NlaEvalChannel *blend_queue;
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
} NlaBlendData;
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
/* Queue the channel for deferred blending. */
static NlaEvalChannelSnapshot *nlaevalchan_queue_blend(NlaBlendData *blend, NlaEvalChannel *nec)
{
if (!nec->in_blend) {
if (nec->blend_snapshot == NULL) {
nec->blend_snapshot = nlaevalchan_snapshot_new(nec);
}
nec->in_blend = true;
nlaevalchan_snapshot_copy(nec->blend_snapshot, &nec->base_snapshot);
nec->next_blend = blend->blend_queue;
blend->blend_queue = nec;
}
return nec->blend_snapshot;
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* Accumulate (i.e. blend) the given value on to the channel it affects. */
static bool nlaeval_blend_value(NlaBlendData *blend, NlaEvalChannel *nec, int array_index, float value)
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
{
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
if (nec == NULL) {
return false;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
int index = nlaevalchan_validate_index(nec, array_index);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
if (index < 0) {
if (G.debug & G_DEBUG) {
ID *id = nec->key.ptr.id.data;
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_WARN(&LOG, "Animato: 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);
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
return false;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
if (nec->mix_mode == NEC_MIX_QUATERNION) {
/* For quaternion properties, always output all sub-channels. */
BLI_bitmap_set_all(nec->valid.ptr, true, 4);
}
else {
BLI_BITMAP_ENABLE(nec->valid.ptr, index);
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaEvalChannelSnapshot *nec_snapshot = nlaeval_snapshot_ensure_channel(blend->snapshot, nec);
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
float *p_value = &nec_snapshot->values[index];
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
if (blend->mode == NLASTRIP_MODE_COMBINE) {
/* Quaternion blending is deferred until all sub-channel values are known. */
if (nec->mix_mode == NEC_MIX_QUATERNION) {
NlaEvalChannelSnapshot *blend_snapshot = nlaevalchan_queue_blend(blend, nec);
blend_snapshot->values[index] = value;
}
else {
float base_value = nec->base_snapshot.values[index];
*p_value = nla_combine_value(nec->mix_mode, base_value, *p_value, value, blend->influence);
}
}
else {
*p_value = nla_blend_value(blend->mode, *p_value, value, blend->influence);
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
return true;
}
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
/* Finish deferred quaternion blending. */
static void nlaeval_blend_flush(NlaBlendData *blend)
{
NlaEvalChannel *nec;
while ((nec = blend->blend_queue)) {
blend->blend_queue = nec->next_blend;
nec->in_blend = false;
NlaEvalChannelSnapshot *nec_snapshot = nlaeval_snapshot_ensure_channel(blend->snapshot, nec);
NlaEvalChannelSnapshot *blend_snapshot = nec->blend_snapshot;
if (nec->mix_mode == NEC_MIX_QUATERNION) {
nla_combine_quaternion(nec_snapshot->values, blend_snapshot->values, blend->influence, nec_snapshot->values);
}
else {
BLI_assert(!"mix quaternion");
}
}
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
/* Blend the specified snapshots into the target, and free the input snapshots. */
static void nlaeval_snapshot_mix_and_free(NlaEvalData *nlaeval, NlaEvalSnapshot *out, NlaEvalSnapshot *in1, NlaEvalSnapshot *in2, float alpha)
{
BLI_assert(in1->base == out && in2->base == out);
nlaeval_snapshot_ensure_size(out, nlaeval->num_channels);
for (int i = 0; i < nlaeval->num_channels; i++) {
NlaEvalChannelSnapshot *c_in1 = nlaeval_snapshot_get(in1, i);
NlaEvalChannelSnapshot *c_in2 = nlaeval_snapshot_get(in2, i);
if (c_in1 || c_in2) {
NlaEvalChannelSnapshot *c_out = out->channels[i];
/* Steal the entry from one of the input snapshots. */
if (c_out == NULL) {
if (c_in1 != NULL) {
c_out = c_in1;
in1->channels[i] = NULL;
}
else {
c_out = c_in2;
in2->channels[i] = NULL;
}
}
if (c_in1 == NULL) {
c_in1 = nlaeval_snapshot_find_channel(in1->base, c_out->channel);
}
if (c_in2 == NULL) {
c_in2 = nlaeval_snapshot_find_channel(in2->base, c_out->channel);
}
out->channels[i] = c_out;
for (int j = 0; j < c_out->length; j++) {
c_out->values[j] = c_in1->values[j] * (1.0f - alpha) + c_in2->values[j] * alpha;
}
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlaeval_snapshot_free_data(in1);
nlaeval_snapshot_free_data(in2);
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
}
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
/* ---------------------- */
/* F-Modifier stack joining/separation utilities - should we generalise these for BLI_listbase.h interface? */
/* Temporarily join two lists of modifiers together, storing the result in a third list */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void nlaeval_fmodifiers_join_stacks(ListBase *result, ListBase *list1, ListBase *list2)
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
{
FModifier *fcm1, *fcm2;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
/* if list1 is invalid... */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, list1, list1->first)) {
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
if (list2 && list2->first) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
result->first = list2->first;
result->last = list2->last;
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
}
}
/* if list 2 is invalid... */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
else if (ELEM(NULL, list2, list2->first)) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
result->first = list1->first;
result->last = list1->last;
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
}
else {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* list1 should be added first, and list2 second, with the endpoints of these being the endpoints for result
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - the original lists must be left unchanged though, as we need that fact for restoring
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
result->first = list1->first;
result->last = list2->last;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
fcm1 = list1->last;
fcm2 = list2->first;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
fcm1->next = fcm2;
fcm2->prev = fcm1;
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
}
}
/* Split two temporary lists of modifiers */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void nlaeval_fmodifiers_split_stacks(ListBase *list1, ListBase *list2)
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
{
FModifier *fcm1, *fcm2;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
/* if list1/2 is invalid... just skip */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, list1, list2))
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
return;
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, list1->first, list2->first))
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
/* get endpoints */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
fcm1 = list1->last;
fcm2 = list2->first;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
/* clear their links */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
fcm1->next = NULL;
fcm2->prev = NULL;
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
}
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
/* ---------------------- */
/* evaluate action-clip strip */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
static void nlastrip_evaluate_actionclip(PointerRNA *ptr, NlaEvalData *channels, ListBase *modifiers, NlaEvalStrip *nes, NlaEvalSnapshot *snapshot)
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
{
Fix crash happening in Cycles fcurve modifier Summary: Crash was happening because of fcurve modifier stack used modifier's DNA to store temporary data. Now made it so storage for such a thing is being allocated locally per object update so multiple objects which shares the same animation wouldn't run into threading conflict anymore. This storage might be a part of EvaluationContext, but that'd mean passing this context all over in object_where_is which will clutter API for now without actual benefit for this. Optimization notes: storage is only being allocated if there're Cycles modifier in the stack, so there're no extra allocations happening in all other cases. To make code a bit less cluttered with this storage passing all over the place added extra callbacks to the FModifier storage which runs evaluation with the given storage. Reviewers: brecht, campbellbarton, aligorith CC: plasmasolutions Differential Revision: https://developer.blender.org/D147
2013-12-29 19:15:37 +06:00
FModifierStackStorage *storage;
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
ListBase tmp_modifiers = {NULL, NULL};
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
NlaStrip *strip = nes->strip;
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
FCurve *fcu;
float evaltime;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
/* sanity checks for action */
if (strip == NULL)
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
if (strip->act == NULL) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "NLA-Strip Eval Error: Strip '%s' has no Action", strip->name);
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
return;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#25960] Action/NLA Editor issues with animdata context Actions now get tagged with an ID-code, which is used to determine what ID-blocks they can be assigned to. This ensures that material actions cannot be assigned to the object-level for example. * Action lists in general will now show only the actions that can be set for that particular slot. This prevents selection of invalid actions, and helps cut down the list of actions. ** An exception here is the Add Action Clip in NLA Editor, which will show all actions but will only add where appropriate. This is because it's not easy/possible to tell in advance which blocktypes to filter for when building this list. (TODO?) * The "Action Editor" is now strictly for object-level action editing+setting now. This avoids repeateded confusion by people who try using this to view their shapekey actions, which should go to the Shape Key Editor instead! ** A context switcher for the legitimate times where this capability might come in handy is still being investigated. * "Floating" actions (i.e. actions in some action_library.blend) are NOT able to be automatically tagged until they are assigned to some datablocks (i.e. loaded onto the rig + played back once). It is possible to write scripts that check for certain RNA-paths and "guess" what datablocks they work on, but it is recommended that you load up the Datablocks Viewer, and go through such actions by hand, setting the "ID Root Type" property as appropriate per action.
2011-04-19 13:01:50 +00:00
action_idcode_patch_check(ptr->id.data, strip->act);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
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);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
/* evaluate strip's modifiers which modify time to evaluate the base curves at */
Fix crash happening in Cycles fcurve modifier Summary: Crash was happening because of fcurve modifier stack used modifier's DNA to store temporary data. Now made it so storage for such a thing is being allocated locally per object update so multiple objects which shares the same animation wouldn't run into threading conflict anymore. This storage might be a part of EvaluationContext, but that'd mean passing this context all over in object_where_is which will clutter API for now without actual benefit for this. Optimization notes: storage is only being allocated if there're Cycles modifier in the stack, so there're no extra allocations happening in all other cases. To make code a bit less cluttered with this storage passing all over the place added extra callbacks to the FModifier storage which runs evaluation with the given storage. Reviewers: brecht, campbellbarton, aligorith CC: plasmasolutions Differential Revision: https://developer.blender.org/D147
2013-12-29 19:15:37 +06:00
storage = evaluate_fmodifiers_storage_new(&tmp_modifiers);
evaltime = evaluate_time_fmodifiers(storage, &tmp_modifiers, NULL, 0.0f, strip->strip_time);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaBlendData blend = {
.snapshot = snapshot,
.mode = strip->blendmode,
.influence = strip->influence,
};
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
/* evaluate all the F-Curves in the action, saving the relevant pointers to data that will need to be used */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (fcu = strip->act->curves.first; fcu; fcu = fcu->next) {
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
float value = 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
/* check if this curve should be skipped */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if (fcu->flag & (FCURVE_MUTED | FCURVE_DISABLED))
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
continue;
NLA SoC: Muting and Graph-Editor Curve visibility for (Action) Groups Groups (the Action variety) can now be muted, and also be set to not be drawn in the Graph Editor. These settings get applied to all the F-Curves within the group, overriding any settings individual F-Curves might have, allowing users to quickly mute or hide groups of curves without having to go through clicking on all of them. Also, added a flag that can be used to set the curve visiblity on AnimData level too. This will be enabled in a future commit.
2009-07-03 10:28:10 +00:00
if ((fcu->grp) && (fcu->grp->flag & AGRP_MUTED))
continue;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* evaluate the F-Curve's value for the time given in the strip
* NOTE: we use the modified time here, since strip's F-Curve Modifiers are applied on top of this
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
value = evaluate_fcurve(fcu, evaltime);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* apply strip's F-Curve Modifiers on this value
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
* NOTE: we apply the strip's original evaluation time not the modified one (as per standard F-Curve eval)
*/
Fix crash happening in Cycles fcurve modifier Summary: Crash was happening because of fcurve modifier stack used modifier's DNA to store temporary data. Now made it so storage for such a thing is being allocated locally per object update so multiple objects which shares the same animation wouldn't run into threading conflict anymore. This storage might be a part of EvaluationContext, but that'd mean passing this context all over in object_where_is which will clutter API for now without actual benefit for this. Optimization notes: storage is only being allocated if there're Cycles modifier in the stack, so there're no extra allocations happening in all other cases. To make code a bit less cluttered with this storage passing all over the place added extra callbacks to the FModifier storage which runs evaluation with the given storage. Reviewers: brecht, campbellbarton, aligorith CC: plasmasolutions Differential Revision: https://developer.blender.org/D147
2013-12-29 19:15:37 +06:00
evaluate_value_fmodifiers(storage, &tmp_modifiers, fcu, &value, strip->strip_time);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
/* get an NLA evaluation channel to work with, and accumulate the evaluated value with the value(s)
* stored in this channel if it has been used already
*/
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaEvalChannel *nec = nlaevalchan_verify(ptr, channels, fcu->rna_path);
nlaeval_blend_value(&blend, nec, fcu->array_index, value);
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
}
Fix crash happening in Cycles fcurve modifier Summary: Crash was happening because of fcurve modifier stack used modifier's DNA to store temporary data. Now made it so storage for such a thing is being allocated locally per object update so multiple objects which shares the same animation wouldn't run into threading conflict anymore. This storage might be a part of EvaluationContext, but that'd mean passing this context all over in object_where_is which will clutter API for now without actual benefit for this. Optimization notes: storage is only being allocated if there're Cycles modifier in the stack, so there're no extra allocations happening in all other cases. To make code a bit less cluttered with this storage passing all over the place added extra callbacks to the FModifier storage which runs evaluation with the given storage. Reviewers: brecht, campbellbarton, aligorith CC: plasmasolutions Differential Revision: https://developer.blender.org/D147
2013-12-29 19:15:37 +06:00
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
nlaeval_blend_flush(&blend);
Fix crash happening in Cycles fcurve modifier Summary: Crash was happening because of fcurve modifier stack used modifier's DNA to store temporary data. Now made it so storage for such a thing is being allocated locally per object update so multiple objects which shares the same animation wouldn't run into threading conflict anymore. This storage might be a part of EvaluationContext, but that'd mean passing this context all over in object_where_is which will clutter API for now without actual benefit for this. Optimization notes: storage is only being allocated if there're Cycles modifier in the stack, so there're no extra allocations happening in all other cases. To make code a bit less cluttered with this storage passing all over the place added extra callbacks to the FModifier storage which runs evaluation with the given storage. Reviewers: brecht, campbellbarton, aligorith CC: plasmasolutions Differential Revision: https://developer.blender.org/D147
2013-12-29 19:15:37 +06:00
/* free temporary storage */
evaluate_fmodifiers_storage_free(storage);
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
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);
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
}
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
/* evaluate transition strip */
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
static void nlastrip_evaluate_transition(
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
Depsgraph *depsgraph, PointerRNA *ptr, NlaEvalData *channels, ListBase *modifiers, NlaEvalStrip *nes, NlaEvalSnapshot *snapshot)
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
{
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
ListBase tmp_modifiers = {NULL, NULL};
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaEvalSnapshot snapshot1, snapshot2;
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
NlaEvalStrip tmp_nes;
NlaStrip *s1, *s2;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
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);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* get the two strips to operate on
Cleanup: comment block tabs
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
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
*/
if (nes->strip->flag & NLASTRIP_FLAG_REVERSE) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
s1 = nes->strip->next;
s2 = nes->strip->prev;
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
}
else {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
s1 = nes->strip->prev;
s2 = nes->strip->next;
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* prepare template for 'evaluation strip'
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - 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
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
tmp_nes = *nes;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +00:00
/* evaluate these strips into a temp-buffer (tmp_channels) */
Correcting a few typos
2013-11-05 10:57:52 +00:00
/* FIXME: modifier evaluation here needs some work... */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
/* first strip */
tmp_nes.strip_mode = NES_TIME_TRANSITION_START;
tmp_nes.strip = s1;
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlaeval_snapshot_init(&snapshot1, channels, snapshot);
nlastrip_evaluate(depsgraph, ptr, channels, &tmp_modifiers, &tmp_nes, &snapshot1);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
/* second strip */
tmp_nes.strip_mode = NES_TIME_TRANSITION_END;
tmp_nes.strip = s2;
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlaeval_snapshot_init(&snapshot2, channels, snapshot);
nlastrip_evaluate(depsgraph, ptr, channels, &tmp_modifiers, &tmp_nes, &snapshot2);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Correcting a few typos
2013-11-05 10:57:52 +00:00
/* accumulate temp-buffer and full-buffer, using the 'real' strip */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlaeval_snapshot_mix_and_free(channels, snapshot, &snapshot1, &snapshot2, nes->strip_time);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
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);
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
}
/* evaluate meta-strip */
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
static void nlastrip_evaluate_meta(
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
Depsgraph *depsgraph, PointerRNA *ptr, NlaEvalData *channels, ListBase *modifiers, NlaEvalStrip *nes, NlaEvalSnapshot *snapshot)
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
{
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
ListBase tmp_modifiers = {NULL, NULL};
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
NlaStrip *strip = nes->strip;
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
NlaEvalStrip *tmp_nes;
float evaltime;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
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
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
* it's child strips, which get evaluated as if they were some tracks on a strip
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
* (but with some extra modifiers to apply).
*
* NOTE: keep this in sync with animsys_evaluate_nla()
*/
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
2009-07-07 12:17:06 +00:00
/* join this strip's modifiers to the parent's modifiers (own modifiers first) */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
nlaeval_fmodifiers_join_stacks(&tmp_modifiers, &strip->modifiers, modifiers);
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
/* find the child-strip to evaluate */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
evaltime = (nes->strip_time * (strip->end - strip->start)) + strip->start;
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
tmp_nes = nlastrips_ctime_get_strip(depsgraph, NULL, &strip->strips, -1, evaltime);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* directly evaluate child strip into accumulation buffer...
Bugfix T40082: NLA Meta strips were no longer evaluating correctly It seems that since the changes to how new NLA strips are handled, accumulating these in a temporary buffer and then trying to combine the results didn't work that great anymore.
2014-05-08 21:00:59 +12:00
* - there's no need to use a temporary buffer (as it causes issues [T40082])
*/
Fix for random crashes when grabbing (rmb-drag) NLA strips Although these crashes were quite sporadic, they seemed to happen most when rmb-dragging strips randomly in quick succession. The most likely cause seems to be a null check I accidentally took out during one of my commits yesterday.
2014-05-10 00:18:47 +12:00
if (tmp_nes) {
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlastrip_evaluate(depsgraph, ptr, channels, &tmp_modifiers, tmp_nes, snapshot);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix for random crashes when grabbing (rmb-drag) NLA strips Although these crashes were quite sporadic, they seemed to happen most when rmb-dragging strips randomly in quick succession. The most likely cause seems to be a null check I accidentally took out during one of my commits yesterday.
2014-05-10 00:18:47 +12:00
/* free temp eval-strip */
MEM_freeN(tmp_nes);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: Meta Strips + F-Modifiers F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list. Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
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);
NLA SoC: Transition Strips + Strip Adding Operators + Bugfixes == Transitions == Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them). - The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values... - Transform code needs a few fixes still to deal with these == Strip Adding Operators == * New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though. The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track. * New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work. == New Backend Methods == * Recoded the strip/track adding API to be more flexible * Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix... == Bugfixes == - Fixed bug with strip-blending which caused the blending modes to be useless. - NLA buttons now use proper poll callbacks instead of defining checks - Commented out missing operator in menus, silencing warnings in console - Removed obsolete/incorrect comments
2009-06-19 04:45:56 +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
/* evaluates the given evaluation strip */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
void nlastrip_evaluate(Depsgraph *depsgraph, PointerRNA *ptr, NlaEvalData *channels, ListBase *modifiers, NlaEvalStrip *nes, NlaEvalSnapshot *snapshot)
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
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
NlaStrip *strip = nes->strip;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA Bugfixes: * Fixed crash when anim-playback is running and a strip beside a transition gets transformed. Transition strips no-longer assume that their neighbours are action-clips, using the standard NLA-strip evaluation function instead to evaluate their neighbours. However, a check for ping-pong recursion needed to be added there, so that a transition beside a meta-strip, with the meta having a transition nested at the start of one of its levels, wouldn't fail with stack overflow. * Moved 'Tweak Mode' menu entry to Edit menu, since it's not really that modal.
2009-07-12 04:29:36 +00: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
*/
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: be careful with this flag, since some edit tools may be running and have set this while animplayback was running */
NLA Bugfixes: * Fixed crash when anim-playback is running and a strip beside a transition gets transformed. Transition strips no-longer assume that their neighbours are action-clips, using the standard NLA-strip evaluation function instead to evaluate their neighbours. However, a check for ping-pong recursion needed to be added there, so that a transition beside a meta-strip, with the meta having a transition nested at the start of one of its levels, wouldn't fail with stack overflow. * Moved 'Tweak Mode' menu entry to Edit menu, since it's not really that modal.
2009-07-12 04:29:36 +00:00
if (strip->flag & NLASTRIP_FLAG_EDIT_TOUCHED)
return;
strip->flag |= NLASTRIP_FLAG_EDIT_TOUCHED;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
/* actions to take depend on the type of strip */
NLA Bugfixes: * Fixed crash when anim-playback is running and a strip beside a transition gets transformed. Transition strips no-longer assume that their neighbours are action-clips, using the standard NLA-strip evaluation function instead to evaluate their neighbours. However, a check for ping-pong recursion needed to be added there, so that a transition beside a meta-strip, with the meta having a transition nested at the start of one of its levels, wouldn't fail with stack overflow. * Moved 'Tweak Mode' menu entry to Edit menu, since it's not really that modal.
2009-07-12 04:29:36 +00:00
switch (strip->type) {
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
case NLASTRIP_TYPE_CLIP: /* action-clip */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlastrip_evaluate_actionclip(ptr, channels, modifiers, nes, snapshot);
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
break;
case NLASTRIP_TYPE_TRANSITION: /* transition */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlastrip_evaluate_transition(depsgraph, ptr, channels, modifiers, nes, snapshot);
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
break;
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
case NLASTRIP_TYPE_META: /* meta */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlastrip_evaluate_meta(depsgraph, ptr, channels, modifiers, nes, snapshot);
NLA SoC: Recoded way that Meta-Strips are Evaluated Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable. This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference. TODO: * F-Modifier support for Metas...
2009-07-07 11:37:33 +00:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Sound clip NLA Strips for Nexyon These are basically just for specifying when a speaker should fire off it's soundclip, and as such, many NLA operations are irrelevant for it. They can only be specified on object-level for speaker objects. I've still got some UI tweaks I'll need to work on in order for these to be able to be added even when the speaker doesn't have any NLA tracks yet. (EDIT: while typing this, I had an idea for how to do this, but that'll be for next commit). In the mean time, you'll need to add a single keyframe for the object, snowflake that action and delete the NLA strip before you can start editing.
2011-08-07 12:27:20 +00:00
default: /* do nothing */
break;
NLA Branch: Setting up evaluation system for action strips * Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips * Started setting up temporary accumulation buffer system for use when evaluating strips
2009-05-15 13:23:03 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA Bugfixes: * Fixed crash when anim-playback is running and a strip beside a transition gets transformed. Transition strips no-longer assume that their neighbours are action-clips, using the standard NLA-strip evaluation function instead to evaluate their neighbours. However, a check for ping-pong recursion needed to be added there, so that a transition beside a meta-strip, with the meta having a transition nested at the start of one of its levels, wouldn't fail with stack overflow. * Moved 'Tweak Mode' menu entry to Edit menu, since it's not really that modal.
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
}
/* write the accumulated settings to */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
void nladata_flush_channels(Depsgraph *depsgraph, PointerRNA *ptr, NlaEvalData *channels, NlaEvalSnapshot *snapshot)
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 SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
/* sanity checks */
if (channels == NULL)
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: use animsys_write_orig_anim_rna when applying NLA stack results. Without this keyframing on top of an NLA stack is quite weirdly broken.
2018-11-07 19:47:22 +03:00
const bool is_active_depsgraph = DEG_is_active(depsgraph);
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
2009-05-16 01:00:41 +00:00
/* for each channel with accumulated values, write its value on the property it affects */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
for (NlaEvalChannel *nec = channels->channels.first; nec; nec = nec->next) {
NlaEvalChannelSnapshot *nec_snapshot = nlaeval_snapshot_find_channel(snapshot, nec);
PathResolvedRNA rna = { nec->key.ptr, nec->key.prop, -1 };
for (int i = 0; i < nec_snapshot->length; i++) {
if (BLI_BITMAP_TEST(nec->valid.ptr, i)) {
float value = nec_snapshot->values[i];
if (nec->is_array) {
rna.prop_index = i;
}
animsys_write_rna_setting(&rna, value);
if (is_active_depsgraph) {
animsys_write_orig_anim_rna(ptr, nec->rna_path, rna.prop_index, value);
}
}
NLA SoC: Code for basic evaluation of NLA strips done In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions... Some notes: * Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work. * Some assorted code cleanups done too (removing unneeded vars/args)
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
}
/* ---------------------- */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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;
}
for (FCurve *fcu = act->curves.first; fcu; fcu = fcu->next) {
/* check if this curve should be skipped */
if (fcu->flag & (FCURVE_MUTED | FCURVE_DISABLED))
continue;
if ((fcu->grp) && (fcu->grp->flag & AGRP_MUTED))
continue;
NlaEvalChannel *nec = nlaevalchan_verify(ptr, channels, fcu->rna_path);
if (nec != NULL) {
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
/* For quaternion properties, enable all sub-channels. */
if (nec->mix_mode == NEC_MIX_QUATERNION) {
BLI_bitmap_set_all(nec->valid.ptr, true, 4);
continue;
}
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
int idx = nlaevalchan_validate_index(nec, fcu->array_index);
if (idx >= 0) {
BLI_BITMAP_ENABLE(nec->valid.ptr, idx);
}
}
}
}
static void nla_eval_domain_strips(PointerRNA *ptr, NlaEvalData *channels, ListBase *strips, GSet *touched_actions)
{
for (NlaStrip *strip = strips->first; strip; strip = strip->next) {
/* check strip's action */
if (strip->act) {
nla_eval_domain_action(ptr, channels, strip->act, touched_actions);
}
/* check sub-strips (if metas) */
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__);
if (adt->action) {
nla_eval_domain_action(ptr, channels, adt->action, touched_actions);
}
/* NLA Data - Animation Data for Strips */
for (NlaTrack *nlt = adt->nla_tracks.first; nlt; nlt = nlt->next) {
/* 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)
continue;
/* else - mute doesn't matter */
}
else {
/* no solo tracks - skip track if muted */
if (nlt->flag & NLATRACK_MUTED)
continue;
}
nla_eval_domain_strips(ptr, channels, &nlt->strips, touched_actions);
}
BLI_gset_free(touched_actions, NULL);
}
/* ---------------------- */
Cleanup: Use doxy for more structured comments
2014-05-29 21:16:04 +10:00
/**
* NLA Evaluation function - values are calculated and stored in temporary "NlaEvalChannels"
*
Comments: Note direction in doxy args
2014-05-29 22:05:07 +10:00
* \param[out] echannels Evaluation channels with calculated values
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
* \param[out] r_context If not NULL, data about the currently edited strip is stored here and excluded from value calculation.
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
* \return false if NLA evaluation isn't actually applicable
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: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
static bool animsys_evaluate_nla(Depsgraph *depsgraph, NlaEvalData *echannels, PointerRNA *ptr, AnimData *adt, float ctime, NlaKeyframingContext *r_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
{
NlaTrack *nlt;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
short track_index = 0;
Code cleanup: use booleans where appropriate
2014-01-28 03:52:21 +11:00
bool has_strips = false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ListBase estrips = {NULL, NULL};
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;
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
NlaStrip dummy_strip_buf;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
/* dummy strip for active action */
NlaStrip *dummy_strip = r_context ? &r_context->strip : &dummy_strip_buf;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
memset(dummy_strip, 0, sizeof(*dummy_strip));
Cleanup: trailing space for blenkernel
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
/* 1. get the stack of strips to evaluate at current time (influence calculated here) */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (nlt = adt->nla_tracks.first; nlt; nlt = nlt->next, track_index++) {
Bugfix #24143: Edit NLA Strips When editing an action used by a NLA strip and editing it 'in place' (controlled by pin icon on green 'tweaking' channel), the animation would only get played back in the action's original frame range while the keyframes were still displayed in the strip-altered positions.
2010-10-16 04:14:26 +00:00
/* stop here if tweaking is on and this strip is the tweaking track (it will be the first one that's 'disabled')... */
NLA SoC: NLA-Evaluation Bugfixes * Fixed an evil bug where the last frame of a strip was always incorrectly evaluated. This was because these frames were not being included in the strip's 'range' as defined by the IN_RANGE() testing macro, which only considers the given range as an open interval (i.e. non-inclusive of boundary points). I've added a new macro, IN_RANGE_INCL(), which is inclusive of boundary points, since this is a common test in many other parts of the code. * When an AnimData block is in 'tweaking' mode, the tracks following (and including the active track) are now correctly skipped during evaluation. * Finished coding the option of setting a single NLA-track per NLA-block to play 'solo' (i.e. only that track is enabled for evaluation). To enable this, simply click on one of the grey 'dots' beside the NLA-track names, turning this dot yellow. The 'yellow' dot means that the track will play by itself (even the 'active action' gets silenced). Only one track per AnimData block can play solo at a time. To disable, simply click on the 'yellow' dot again. NOTE: this currently uses the View3D layer-status icons. We probably need some special ones for these later (coloured vs grey star?) * Also (not related to evaluation) made the selection operators for the NLA Editor only work when not in tweaking mode, since in tweaking mode they can potentially result in data being resolved inappropriately when leaving tweaking mode.
2009-06-05 11:51:27 +00:00
if ((adt->flag & ADT_NLA_EDIT_ON) && (nlt->flag & NLATRACK_DISABLED))
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix for NLA Solo/Mute behaviour The Solo and Mute functionality for the NLA system should really be mutually exclusive features. They both affect whether a given track applies or not. The only difference is that the Solo option mutes all the others, while the Mute only does this on a per track basis. Before this fix, muting a strip and then making it solo meant that the solo'd track would not play at all, which isn't really what we want.
2015-02-27 19:36:13 +13: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 */
if ((nlt->flag & NLATRACK_SOLO) == 0)
continue;
/* else - mute doesn't matter */
}
else {
/* no solo tracks - skip track if muted */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
if (nlt->flag & NLATRACK_MUTED)
Fix for NLA Solo/Mute behaviour The Solo and Mute functionality for the NLA system should really be mutually exclusive features. They both affect whether a given track applies or not. The only difference is that the Solo option mutes all the others, while the Mute only does this on a per track basis. Before this fix, muting a strip and then making it solo meant that the solo'd track would not play at all, which isn't really what we want.
2015-02-27 19:36:13 +13:00
continue;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* if this track has strips (but maybe they won't be suitable), set has_strips
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - used for mainly for still allowing normal action evaluation...
NLA - Quick patch bugfix When there were no strips but some empty tracks, the active action should be evaluated normally. This is not an optimal solution (more user testing + suggestions regarding the best way to do this is welcome).
2009-08-04 10:31:25 +00:00
*/
if (nlt->strips.first)
Bugfix T40082: NLA Meta strips were no longer evaluating correctly It seems that since the changes to how new NLA strips are handled, accumulating these in a temporary buffer and then trying to combine the results didn't work that great anymore.
2014-05-08 21:00:59 +12:00
has_strips = true;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA SoC: NLA-Evaluation Bugfixes * Fixed an evil bug where the last frame of a strip was always incorrectly evaluated. This was because these frames were not being included in the strip's 'range' as defined by the IN_RANGE() testing macro, which only considers the given range as an open interval (i.e. non-inclusive of boundary points). I've added a new macro, IN_RANGE_INCL(), which is inclusive of boundary points, since this is a common test in many other parts of the code. * When an AnimData block is in 'tweaking' mode, the tracks following (and including the active track) are now correctly skipped during evaluation. * Finished coding the option of setting a single NLA-track per NLA-block to play 'solo' (i.e. only that track is enabled for evaluation). To enable this, simply click on one of the grey 'dots' beside the NLA-track names, turning this dot yellow. The 'yellow' dot means that the track will play by itself (even the 'active action' gets silenced). Only one track per AnimData block can play solo at a time. To disable, simply click on the 'yellow' dot again. NOTE: this currently uses the View3D layer-status icons. We probably need some special ones for these later (coloured vs grey star?) * Also (not related to evaluation) made the selection operators for the NLA Editor only work when not in tweaking mode, since in tweaking mode they can potentially result in data being resolved inappropriately when leaving tweaking mode.
2009-06-05 11:51:27 +00:00
/* otherwise, get strip to evaluate for this channel */
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
nes = nlastrips_ctime_get_strip(depsgraph, &estrips, &nlt->strips, track_index, ctime);
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if (nes) nes->track = nlt;
NLA SoC: NLA-Evaluation Bugfixes * Fixed an evil bug where the last frame of a strip was always incorrectly evaluated. This was because these frames were not being included in the strip's 'range' as defined by the IN_RANGE() testing macro, which only considers the given range as an open interval (i.e. non-inclusive of boundary points). I've added a new macro, IN_RANGE_INCL(), which is inclusive of boundary points, since this is a common test in many other parts of the code. * When an AnimData block is in 'tweaking' mode, the tracks following (and including the active track) are now correctly skipped during evaluation. * Finished coding the option of setting a single NLA-track per NLA-block to play 'solo' (i.e. only that track is enabled for evaluation). To enable this, simply click on one of the grey 'dots' beside the NLA-track names, turning this dot yellow. The 'yellow' dot means that the track will play by itself (even the 'active action' gets silenced). Only one track per AnimData block can play solo at a time. To disable, simply click on the 'yellow' dot again. NOTE: this currently uses the View3D layer-status icons. We probably need some special ones for these later (coloured vs grey star?) * Also (not related to evaluation) made the selection operators for the NLA Editor only work when not in tweaking mode, since in tweaking mode they can potentially result in data being resolved inappropriately when leaving tweaking mode.
2009-06-05 11:51:27 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - NLA + Realtime Animating Goodies * When doing realtime recording of animation (i.e. transforming objects + bones while animation playback is running, and auto-keying is enabled), animation will be added to a new NLA Track+Strip combo everytime a single 'loop' of the frame range has finished. This will allow 'passes' over the animation to be less destructive. * Made the evaluation of the active action (when NLA data is present), be handled as part of the normal NLA system evaluation code (as if it were just another strip in a track at the end). The immediate benefit is that there are now some settings (available in the "Animation Data" panel in the NLA Editor with a strip selected) which allow for the way the active action is combined with the NLA stack results. For instance, the way that the action extrapolates is used in the recording tweaks above.
2009-07-31 07:43:47 +00:00
/* add 'active' Action (may be tweaking track) as last strip to evaluate in NLA stack
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - only do this if we're not exclusively evaluating the 'solo' NLA-track
* - however, if the 'solo' track houses the current 'tweaking' strip,
* then we should allow this to play, otherwise nothing happens
Animato - NLA + Realtime Animating Goodies * When doing realtime recording of animation (i.e. transforming objects + bones while animation playback is running, and auto-keying is enabled), animation will be added to a new NLA Track+Strip combo everytime a single 'loop' of the frame range has finished. This will allow 'passes' over the animation to be less destructive. * Made the evaluation of the active action (when NLA data is present), be handled as part of the normal NLA system evaluation code (as if it were just another strip in a track at the end). The immediate benefit is that there are now some settings (available in the "Animation Data" panel in the NLA Editor with a strip selected) which allow for the way the active action is combined with the NLA stack results. For instance, the way that the action extrapolates is used in the recording tweaks above.
2009-07-31 07:43:47 +00:00
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ((adt->action) && ((adt->flag & ADT_NLA_SOLO_TRACK) == 0 || (adt->flag & ADT_NLA_EDIT_ON))) {
NLA - Quick patch bugfix When there were no strips but some empty tracks, the active action should be evaluated normally. This is not an optimal solution (more user testing + suggestions regarding the best way to do this is welcome).
2009-08-04 10:31:25 +00:00
/* if there are strips, evaluate action as per NLA rules */
Bugfix #24143: Edit NLA Strips When editing an action used by a NLA strip and editing it 'in place' (controlled by pin icon on green 'tweaking' channel), the animation would only get played back in the action's original frame range while the keyframes were still displayed in the strip-altered positions.
2010-10-16 04:14:26 +00:00
if ((has_strips) || (adt->actstrip)) {
NLA - Quick patch bugfix When there were no strips but some empty tracks, the active action should be evaluated normally. This is not an optimal solution (more user testing + suggestions regarding the best way to do this is welcome).
2009-08-04 10:31:25 +00:00
/* make dummy NLA strip, and add that to the stack */
use zero initializers instead of memset(), also change PointerRNA_NULL from an extern into a define.
2010-11-23 08:44:21 +00:00
ListBase dummy_trackslist;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
dummy_trackslist.first = dummy_trackslist.last = dummy_strip;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
/* 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. */
bool is_inplace_tweak = (nlt) && !(adt->flag & ADT_NLA_EDIT_NOMAP) && !(adt->actstrip->flag & NLASTRIP_FLAG_USR_TIME);
if (is_inplace_tweak) {
Bugfix #24143: Edit NLA Strips When editing an action used by a NLA strip and editing it 'in place' (controlled by pin icon on green 'tweaking' channel), the animation would only get played back in the action's original frame range while the keyframes were still displayed in the strip-altered positions.
2010-10-16 04:14:26 +00:00
/* edit active action in-place according to its active strip, so copy the data */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
memcpy(dummy_strip, adt->actstrip, sizeof(NlaStrip));
dummy_strip->next = dummy_strip->prev = NULL;
Bugfix #24143: Edit NLA Strips When editing an action used by a NLA strip and editing it 'in place' (controlled by pin icon on green 'tweaking' channel), the animation would only get played back in the action's original frame range while the keyframes were still displayed in the strip-altered positions.
2010-10-16 04:14:26 +00:00
}
else {
/* set settings of dummy NLA strip from AnimData settings */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
dummy_strip->act = adt->action;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #24143: Edit NLA Strips When editing an action used by a NLA strip and editing it 'in place' (controlled by pin icon on green 'tweaking' channel), the animation would only get played back in the action's original frame range while the keyframes were still displayed in the strip-altered positions.
2010-10-16 04:14:26 +00:00
/* action range is calculated taking F-Modifiers into account (which making new strips doesn't do due to the troublesome nature of that) */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
calc_action_range(dummy_strip->act, &dummy_strip->actstart, &dummy_strip->actend, 1);
dummy_strip->start = dummy_strip->actstart;
dummy_strip->end = (IS_EQF(dummy_strip->actstart, dummy_strip->actend)) ? (dummy_strip->actstart + 1.0f) : (dummy_strip->actend);
/* Always use the blend mode of the strip in tweak mode, even if not in-place. */
if (nlt && adt->actstrip) {
dummy_strip->blendmode = adt->actstrip->blendmode;
NLA: ignore time range when evaluating a raw action. When editing an action without a strip, or tweaking a strip without time mapping enabled or supported, the extents of the virtual strip can't be controlled and are purely derived from keys in the action. Thus, cutting off evaluation of the action at these arbitrary points gets in the way of observing the natural extrapolation of the F-Curves and thus appears to be a mis-feature. With this change non-mapped actions are evaluated with infinite range, exactly like they are handled without NLA, unless extend mode is set to Nothing.
2019-01-12 14:10:09 +03:00
dummy_strip->extendmode = NLASTRIP_EXTEND_HOLD;
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
}
else {
dummy_strip->blendmode = adt->act_blendmode;
dummy_strip->extendmode = adt->act_extendmode;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: ignore time range when evaluating a raw action. When editing an action without a strip, or tweaking a strip without time mapping enabled or supported, the extents of the virtual strip can't be controlled and are purely derived from keys in the action. Thus, cutting off evaluation of the action at these arbitrary points gets in the way of observing the natural extrapolation of the F-Curves and thus appears to be a mis-feature. With this change non-mapped actions are evaluated with infinite range, exactly like they are handled without NLA, unless extend mode is set to Nothing.
2019-01-12 14:10:09 +03:00
/* Unless extendmode is Nothing (might be useful for flattening NLA evaluation), disable range. */
if (dummy_strip->extendmode != NLASTRIP_EXTEND_NOTHING) {
dummy_strip->flag |= NLASTRIP_FLAG_NO_TIME_MAP;
}
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
dummy_strip->influence = adt->act_influence;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA Eval Bugfix: Influence settings on active action didn't work * The automatically calculated influence was overriding the value we were passing into the dummy strip, making this seem like it doesn't work * Made some tweaks to prevent some potential memory-related bugs - nlastrips_ctime_get_strip() actually saves off references to the list of strips it gets, so declaring dummy_strip in an inner scope like this could potentially be quite dangerous - Prevented a potential memory leak for the early abort when there are no strips for whatever reason (it shouldn't occur though)
2014-05-03 22:08:35 +12:00
/* NOTE: must set this, or else the default setting overrides, and this setting doesn't work */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
dummy_strip->flag |= NLASTRIP_FLAG_USR_INFLUENCE;
Bugfix #24143: Edit NLA Strips When editing an action used by a NLA strip and editing it 'in place' (controlled by pin icon on green 'tweaking' channel), the animation would only get played back in the action's original frame range while the keyframes were still displayed in the strip-altered positions.
2010-10-16 04:14:26 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA - Quick patch bugfix When there were no strips but some empty tracks, the active action should be evaluated normally. This is not an optimal solution (more user testing + suggestions regarding the best way to do this is welcome).
2009-08-04 10:31:25 +00:00
/* add this to our list of evaluation strips */
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
if (r_context == NULL) {
nlastrips_ctime_get_strip(depsgraph, &estrips, &dummy_trackslist, -1, ctime);
}
/* If computing the context for keyframing, store data there instead of the list. */
else {
/* The extend mode here effectively controls whether it is possible to keyframe beyond the ends. */
dummy_strip->extendmode = is_inplace_tweak ? NLASTRIP_EXTEND_NOTHING : NLASTRIP_EXTEND_HOLD;
r_context->eval_strip = nes = nlastrips_ctime_get_strip(depsgraph, NULL, &dummy_trackslist, -1, ctime);
/* These setting combinations require no data from strips below, so exit immediately. */
if ((nes == NULL) || (dummy_strip->blendmode == NLASTRIP_MODE_REPLACE && dummy_strip->influence == 1.0f)) {
BLI_freelistN(&estrips);
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
return true;
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
}
}
NLA - Quick patch bugfix When there were no strips but some empty tracks, the active action should be evaluated normally. This is not an optimal solution (more user testing + suggestions regarding the best way to do this is welcome).
2009-08-04 10:31:25 +00:00
}
else {
/* special case - evaluate as if there isn't any NLA data */
NLA Eval Bugfix: Influence settings on active action didn't work * The automatically calculated influence was overriding the value we were passing into the dummy strip, making this seem like it doesn't work * Made some tweaks to prevent some potential memory-related bugs - nlastrips_ctime_get_strip() actually saves off references to the list of strips it gets, so declaring dummy_strip in an inner scope like this could potentially be quite dangerous - Prevented a potential memory leak for the early abort when there are no strips for whatever reason (it shouldn't occur though)
2014-05-03 22:08:35 +12:00
BLI_freelistN(&estrips);
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
return false;
NLA - Quick patch bugfix When there were no strips but some empty tracks, the active action should be evaluated normally. This is not an optimal solution (more user testing + suggestions regarding the best way to do this is welcome).
2009-08-04 10:31:25 +00:00
}
Animato - NLA + Realtime Animating Goodies * When doing realtime recording of animation (i.e. transforming objects + bones while animation playback is running, and auto-keying is enabled), animation will be added to a new NLA Track+Strip combo everytime a single 'loop' of the frame range has finished. This will allow 'passes' over the animation to be less destructive. * Made the evaluation of the active action (when NLA data is present), be handled as part of the normal NLA system evaluation code (as if it were just another strip in a track at the end). The immediate benefit is that there are now some settings (available in the "Animation Data" panel in the NLA Editor with a strip selected) which allow for the way the active action is combined with the NLA stack results. For instance, the way that the action extrapolates is used in the recording tweaks above.
2009-07-31 07:43:47 +00:00
}
Cleanup: trailing space for blenkernel
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
/* only continue if there are strips to evaluate */
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
if (BLI_listbase_is_empty(&estrips))
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
return true;
Cleanup: trailing space for blenkernel
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
/* 2. for each strip, evaluate then accumulate on top of existing channels, but don't set values yet */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (nes = estrips.first; nes; nes = nes->next)
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlastrip_evaluate(depsgraph, ptr, echannels, NULL, nes, &echannels->eval_snapshot);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26645] Crash when duplicating an object with driver Missing null check for "improper" driver variables. ------ Also, this commit includes some WIP NLA evaluation reshuffling which should be harmless. I had originally intended this for a later commit...
2011-03-29 09:37:53 +00:00
/* 3. free temporary evaluation data that's not used elsewhere */
BLI_freelistN(&estrips);
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
return true;
Bugfix [#26645] Crash when duplicating an object with driver Missing null check for "improper" driver variables. ------ Also, this commit includes some WIP NLA evaluation reshuffling which should be harmless. I had originally intended this for a later commit...
2011-03-29 09:37:53 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* NLA Evaluation function (mostly for use through do_animdata)
Cleanup: comment block tabs
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.
Bugfix [#26645] Crash when duplicating an object with driver Missing null check for "improper" driver variables. ------ Also, this commit includes some WIP NLA evaluation reshuffling which should be harmless. I had originally intended this for a later commit...
2011-03-29 09:37:53 +00:00
*/
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
static void animsys_calculate_nla(Depsgraph *depsgraph, PointerRNA *ptr, AnimData *adt, float ctime)
Bugfix [#26645] Crash when duplicating an object with driver Missing null check for "improper" driver variables. ------ Also, this commit includes some WIP NLA evaluation reshuffling which should be harmless. I had originally intended this for a later commit...
2011-03-29 09:37:53 +00:00
{
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaEvalData echannels;
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlaeval_init(&echannels);
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
Bugfix [#26645] Crash when duplicating an object with driver Missing null check for "improper" driver variables. ------ Also, this commit includes some WIP NLA evaluation reshuffling which should be harmless. I had originally intended this for a later commit...
2011-03-29 09:37:53 +00:00
/* evaluate the NLA stack, obtaining a set of values to flush */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
if (animsys_evaluate_nla(depsgraph, &echannels, ptr, adt, ctime, NULL)) {
/* 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 */
nladata_flush_channels(depsgraph, ptr, &echannels, &echannels.eval_snapshot);
}
else {
/* special case - evaluate as if there isn't any NLA data */
/* TODO: this is really just a stop-gap measure... */
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
if (G.debug & G_DEBUG) CLOG_WARN(&LOG, "NLA Eval: Stopgap for active action on NLA Stack - no strips case");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
animsys_evaluate_action(depsgraph, ptr, adt->action, ctime);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26645] Crash when duplicating an object with driver Missing null check for "improper" driver variables. ------ Also, this commit includes some WIP NLA evaluation reshuffling which should be harmless. I had originally intended this for a later commit...
2011-03-29 09:37:53 +00:00
/* free temp data */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
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
}
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
/* ---------------------- */
/**
* Prepare data necessary to compute correct keyframe values for NLA strips
* with non-Replace mode or influence different from 1.
*
* @param cache List used to cache contexts for reuse when keying multiple channels in one operation.
* @param ptr RNA pointer to the Object with the animation.
* @return Keyframing context, or NULL if not necessary.
*/
NlaKeyframingContext *BKE_animsys_get_nla_keyframing_context(
struct ListBase *cache, struct Depsgraph *depsgraph, struct PointerRNA *ptr, struct AnimData *adt, float ctime)
{
/* No remapping needed if NLA is off or no action. */
if ((adt == NULL) || (adt->action == NULL) || (adt->nla_tracks.first == NULL) || (adt->flag & ADT_NLA_EVAL_OFF)) {
return NULL;
}
/* No remapping if editing an ordinary Replace action with full influence. */
if (!(adt->flag & ADT_NLA_EDIT_ON) && (adt->act_blendmode == NLASTRIP_MODE_REPLACE && adt->act_influence == 1.0f)) {
return NULL;
}
/* Try to find a cached context. */
NlaKeyframingContext *ctx = BLI_findptr(cache, adt, offsetof(NlaKeyframingContext, adt));
if (ctx == NULL) {
/* Allocate and evaluate a new context. */
ctx = MEM_callocN(sizeof(*ctx), "NlaKeyframingContext");
ctx->adt = adt;
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlaeval_init(&ctx->nla_channels);
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
animsys_evaluate_nla(depsgraph, &ctx->nla_channels, ptr, adt, ctime, ctx);
BLI_assert(ELEM(ctx->strip.act, NULL, adt->action));
BLI_addtail(cache, ctx);
}
return ctx;
}
/**
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
* Apply correction from the NLA context to the values about to be keyframed.
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
*
* @param context Context to use (may be NULL).
* @param prop_ptr Property about to be keyframed.
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
* @param[in,out] values Array of property values to adjust.
* @param count Number of values in the array.
* @param index Index of the element about to be updated, or -1.
* @param[out] r_force_all Set to true if all channels must be inserted. May be NULL.
* @return False if correction fails due to a division by zero, or null r_force_all when all channels are required.
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
*/
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
bool BKE_animsys_nla_remap_keyframe_values(struct NlaKeyframingContext *context, struct PointerRNA *prop_ptr, struct PropertyRNA *prop, float *values, int count, int index, bool *r_force_all)
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
{
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
if (r_force_all != NULL) {
*r_force_all = false;
}
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
/* No context means no correction. */
if (context == NULL || context->strip.act == NULL) {
return true;
}
/* If the strip is not evaluated, it is the same as zero influence. */
if (context->eval_strip == NULL) {
return false;
}
/* Full influence Replace strips also require no correction. */
int blend_mode = context->strip.blendmode;
float influence = context->strip.influence;
if (blend_mode == NLASTRIP_MODE_REPLACE && influence == 1.0f) {
return true;
}
/* Zero influence is division by zero. */
if (influence <= 0.0f) {
return false;
}
/* Find the evaluation channel for the NLA stack below current strip. */
Cleanup: add trailing commas to structs Needed for clang formatting to workaround bug/limit, see: T53211
2019-01-07 00:06:58 +11:00
NlaEvalChannelKey key = { .ptr = *prop_ptr, .prop = prop, };
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaEvalData *nlaeval = &context->nla_channels;
NlaEvalChannel *nec = nlaevalchan_verify_key(nlaeval, NULL, &key);
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
if (nec->base_snapshot.length != count) {
BLI_assert(!"invalid value count");
return false;
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
}
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
/* Invert the blending operation to compute the desired key values. */
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
NlaEvalChannelSnapshot *nec_snapshot = nlaeval_snapshot_find_channel(&nlaeval->eval_snapshot, nec);
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
float *old_values = nec_snapshot->values;
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
if (blend_mode == NLASTRIP_MODE_COMBINE) {
/* Quaternion combine handles all sub-channels as a unit. */
if (nec->mix_mode == NEC_MIX_QUATERNION) {
if (r_force_all == NULL) {
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
return false;
}
NLA: implement a new blending mode that intelligently combines actions. The existing Add and Multiply blending modes have limited usability, because the appropriate operation for meaningfully combining values depends on the channel. This adds a new mode that chooses the operation automatically based on property settings: - Axis+Angle channels are summed, effectively averaging the axis, but adding up the angle. Default is forced to 0. - Quaternion channels use quaternion multiplication: result = prev * value ^ influence - Scale-like multiplicative channels use multiplication: result = prev * (value / default) ^ influence - Other channels use addition: result = prev + (value - default) * influence Inclusion of default in the computation ensures that combining keyframed default values of properties keeps the default state, even if the default isn't 0 or 1. Strips with this mode can be keyframed normally in Tweak mode, except that for quaternion rotation keyframing always inserts all 4 channels, and the channel value sliders on the left side of Graph/Action editors won't insert keys without Auto Key. Quaternion keys are also automatically normalized. Differential Revision: https://developer.blender.org/D4190
2018-12-23 18:43:01 +03:00
*r_force_all = true;
nla_invert_combine_quaternion(old_values, values, influence, values);
}
else {
float *base_values = nec->base_snapshot.values;
for (int i = 0; i < count; i++) {
if (ELEM(index, i, -1)) {
if (!nla_invert_combine_value(nec->mix_mode, base_values[i], old_values[i], values[i], influence, &values[i])) {
return false;
}
}
}
}
}
else {
for (int i = 0; i < count; i++) {
if (ELEM(index, i, -1)) {
if (!nla_invert_blend_value(blend_mode, old_values[i], values[i], influence, &values[i])) {
return false;
}
}
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
}
}
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
Keyframing: refactor insertion code to allow property-global NLA tweaks. Supporting a strip blending type that treats quaternions as a unit also means being able to adjust all sub-channels as a unit when inserting keyframes. This requires refactoring keyframe insertion code to retrieve array property values for all channels at once, before iterating over the indices being inserted.
2019-01-08 18:49:38 +03:00
return true;
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
}
/**
* Free all cached contexts from the list.
*/
void BKE_animsys_free_nla_keyframing_context_cache(struct ListBase *cache)
{
for (NlaKeyframingContext *ctx = cache->first; ctx; ctx = ctx->next) {
MEM_SAFE_FREE(ctx->eval_strip);
NLA: rewrite evaluation channel data structures. Implementing a new intelligent mixing mode that combines quaternions via multiplication requires rewriting the NLA code to recombine array properties from separate scalar channels during evaluation. In addition, stable evaluation of NLA stack requires that any channel that is touched by any of the actions in the stack should always be set to a definite value by evaluation, even if no strip affects it at this point of the timeline. The obvious choice for the fallback is the default value of the property. To make scanning all actions reasonably efficient, mapping paths to channels should be done using hash tables. Differential Revision: https://developer.blender.org/D4120
2018-12-15 16:09:27 +03:00
nlaeval_free(&ctx->nla_channels);
NLA: insert keyframes correctly for strips with non-Replace mode. NLA strips support using the keyframe values in a variety of ways: adding, subtracting, multiplying, linearly mixing with the result of strips located below in the stack. This is intended for layering tweaks on top of a base animation. However, when inserting keyframes into such strips, it simply inserts the final value of the property, irrespective of these settings. This in fact makes the feature nearly useless. To fix this it is necessary to evaluate the NLA stack below the edited strip and correctly compute the raw key that would produce the intended final value, according to the mode and influence. Differential Revision: https://developer.blender.org/D3927
2018-11-12 19:41:53 +03:00
}
BLI_freelistN(cache);
}
Cleanup: trailing space for blenkernel
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 */
style cleanup: whitespace
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
{
AnimOverride *aor;
Cleanup: trailing space for blenkernel
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
/* for each override, simply execute... */
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
for (aor = adt->overrides.first; aor; aor = aor->next) {
PathResolvedRNA anim_rna;
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
if (animsys_store_rna_setting(ptr, aor->rna_path, aor->array_index, &anim_rna)) {
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
animsys_write_rna_setting(&anim_rna, aor->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
}
/* ***************************************** */
/* Evaluation System - Public API */
/* Overview of how this system works:
Cleanup: comment block tabs
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
*
Cleanup: trailing whitespace (comment blocks) Strip unindented comment blocks - mainly headers to avoid conflicts.
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
*
Cleanup: comment block tabs
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.
* Note: it may be necessary to have some tools to handle the cases where some higher-level
* 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
*
Cleanup: trailing whitespace (comment blocks) Strip unindented comment blocks - mainly headers to avoid conflicts.
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
*
Spelling Cleanup
2012-03-01 12:20:18 +00:00
* Maintenance of editability of settings (XXX):
Cleanup: comment block tabs
2018-11-14 12:53:15 +11: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:
Cleanup: comment block tabs
2018-11-14 12:53:15 +11: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?
Animato: Bugfixes * #19501: Only the first user of multi-user IPO's were getting converted to AnimData. Now, this AnimData gets converted multiple times - once for each user. This will mean that multi-user actions will no longer be multi-user after conversion though, although this could be fixed manually if there really is such a need. * #19503: Nasty memory leaks when duplicating objects with AnimData Fixed a few little oversights made when coding the copying code for NLA-data (which resulted in exponential copying-loops of doom), and sanitised the AnimData copying code for ID-blocks to be simpler to manage.
2009-09-30 04:59:14 +00:00
*
* Current Status:
Cleanup: comment block tabs
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
*/
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Evaluation loop for evaluation animation data
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
*
* This assumes that the animation-data provided belongs to the ID block in question,
Cleanup: trailing whitespace (comment blocks) Strip unindented comment blocks - mainly headers to avoid conflicts.
2018-06-01 18:19:39 +02:00
* and that the flags for which parts of the anim-data settings need to be recalculated
* have been set already by the depsgraph. Now, we use the recalc
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
*/
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
void BKE_animsys_evaluate_animdata(Depsgraph *depsgraph, Scene *scene, ID *id, AnimData *adt, float ctime, short recalc)
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
{
PointerRNA id_ptr;
Cleanup: trailing space for blenkernel
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
/* sanity checks */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, 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;
Cleanup: trailing space for blenkernel
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
/* get pointer to ID-block for RNA to use */
RNA_id_pointer_create(id, &id_ptr);
Cleanup: trailing space for blenkernel
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
/* recalculate keyframe data:
Cleanup: comment block tabs
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
*/
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: need to double check that this all works correctly */
Fix T59495, T59992, T59904, T59178, T60598: broken keyframed value editing. This removes a bunch of animation/driver evaluations and recalc flags that should be redundant in the new depsgraph, and were incorrectly affecting the evaluated scene in a permanent way. Still two cases that could be removed if the depsgraph is improved, in BKE_object_handle_data_update and BKE_cachefile_update_frame. For physics subframe interpolation there are also still calls to BKE_object_where_is_calc that should ideally be removed as well, though they are not known to cause keyframing bugs. Differential Revision: https://developer.blender.org/D4274
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 */
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
if ((adt->nla_tracks.first) && !(adt->flag & ADT_NLA_EVAL_OFF)) {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* evaluate NLA-stack
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - active action is evaluated as part of the NLA stack as the last item
NLA SoC: NLA-Evaluation Bugfixes * Fixed an evil bug where the last frame of a strip was always incorrectly evaluated. This was because these frames were not being included in the strip's 'range' as defined by the IN_RANGE() testing macro, which only considers the given range as an open interval (i.e. non-inclusive of boundary points). I've added a new macro, IN_RANGE_INCL(), which is inclusive of boundary points, since this is a common test in many other parts of the code. * When an AnimData block is in 'tweaking' mode, the tracks following (and including the active track) are now correctly skipped during evaluation. * Finished coding the option of setting a single NLA-track per NLA-block to play 'solo' (i.e. only that track is enabled for evaluation). To enable this, simply click on one of the grey 'dots' beside the NLA-track names, turning this dot yellow. The 'yellow' dot means that the track will play by itself (even the 'active action' gets silenced). Only one track per AnimData block can play solo at a time. To disable, simply click on the 'yellow' dot again. NOTE: this currently uses the View3D layer-status icons. We probably need some special ones for these later (coloured vs grey star?) * Also (not related to evaluation) made the selection operators for the NLA Editor only work when not in tweaking mode, since in tweaking mode they can potentially result in data being resolved inappropriately when leaving tweaking mode.
2009-06-05 11:51:27 +00:00
*/
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
animsys_calculate_nla(depsgraph, &id_ptr, adt, 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
}
NLA SoC: NLA-Evaluation Bugfixes * Fixed an evil bug where the last frame of a strip was always incorrectly evaluated. This was because these frames were not being included in the strip's 'range' as defined by the IN_RANGE() testing macro, which only considers the given range as an open interval (i.e. non-inclusive of boundary points). I've added a new macro, IN_RANGE_INCL(), which is inclusive of boundary points, since this is a common test in many other parts of the code. * When an AnimData block is in 'tweaking' mode, the tracks following (and including the active track) are now correctly skipped during evaluation. * Finished coding the option of setting a single NLA-track per NLA-block to play 'solo' (i.e. only that track is enabled for evaluation). To enable this, simply click on one of the grey 'dots' beside the NLA-track names, turning this dot yellow. The 'yellow' dot means that the track will play by itself (even the 'active action' gets silenced). Only one track per AnimData block can play solo at a time. To disable, simply click on the 'yellow' dot again. NOTE: this currently uses the View3D layer-status icons. We probably need some special ones for these later (coloured vs grey star?) * Also (not related to evaluation) made the selection operators for the NLA Editor only work when not in tweaking mode, since in tweaking mode they can potentially result in data being resolved inappropriately when leaving tweaking mode.
2009-06-05 11:51:27 +00:00
/* evaluate Active Action only */
else if (adt->action)
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
animsys_evaluate_action_ex(depsgraph, &id_ptr, adt->action, 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
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* recalculate drivers
Cleanup: comment block tabs
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
*/
Fix T59495, T59992, T59904, T59178, T60598: broken keyframed value editing. This removes a bunch of animation/driver evaluations and recalc flags that should be redundant in the new depsgraph, and were incorrectly affecting the evaluated scene in a permanent way. Still two cases that could be removed if the depsgraph is improved, in BKE_object_handle_data_update and BKE_cachefile_update_frame. For physics subframe interpolation there are also still calls to BKE_object_where_is_calc that should ideally be removed as well, though they are not known to cause keyframing bugs. Differential Revision: https://developer.blender.org/D4274
2019-01-29 11:59:17 +01:00
if (recalc & ADT_RECALC_DRIVERS) {
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
animsys_evaluate_drivers(&id_ptr, adt, ctime);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* always execute 'overrides'
Cleanup: comment block tabs
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
*/
editors/space_* build without unused args warnings
2010-10-16 08:03:28 +00:00
animsys_evaluate_overrides(&id_ptr, adt);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
== 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
/* execute and clear all cached property update functions */
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
if (scene) {
This allows the game engine to build again, but I'm not sure if it's the best approach. Aligorith: feel free to revert this if there is a better solution.
2011-07-28 15:07:32 +00:00
Main *bmain = G.main; // xxx - to get passed in!
RNA_property_update_cache_flush(bmain, scene);
RNA_property_update_cache_free();
}
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 of all ID-blocks with Animation Data blocks - Animation Data Only
*
* This will evaluate only the animation info available in the animation data-blocks
* encountered. In order to enforce the system by which some settings controlled by a
* 'local' (i.e. belonging in the nearest ID-block that setting is related to, not a
* standard 'root') block are overridden by a larger 'user'
*/
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
void BKE_animsys_evaluate_all_animation(Main *main, Depsgraph *depsgraph, Scene *scene, 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;
Merged changes in the trunk up to revision 35828. Conflicts resolved: source/blender/makesrna/RNA_enum_types.h According to the changes in revision 35667, the Freestyle-related code in release/scripts/ui/ was moved to release/scripts/startup/bl_ui/.
2011-03-27 23:11:22 +00:00
move debug flag into its own global var (G.debug), split up debug options. --debug --debug-ffmpeg --debug-python --debug-events --debug-wm This makes debug output easier to read - event debug prints would flood output too much before. For convenience: --debug-all turns all debug flags on (works as --debug did before). also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
2012-03-31 00:59:17 +00:00
if (G.debug & G_DEBUG)
printf("Evaluate all animation - %f\n", ctime);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* macros for less typing
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - 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?
2.5 - Animation Playback Tweaks * Added some optimisations to avoid having to try evaluating some data that won't have any effect. * Converted playback buttons in timeline header to use operators too
2009-08-02 11:05:13 +00:00
*/
#define EVAL_ANIM_IDS(first, aflag) \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (id = first; id; id = id->next) { \
use ID_REAL_USERS macro
2010-05-13 09:22:05 +00:00
if (ID_REAL_USERS(id) > 0) { \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimData *adt = BKE_animdata_from_id(id); \
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
BKE_animsys_evaluate_animdata(depsgraph, scene, id, adt, ctime, aflag); \
use ID_REAL_USERS macro
2010-05-13 09:22:05 +00:00
} \
style cleanup: defines with braces
2012-05-27 20:13:59 +00:00
} (void)0
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* another macro for the "embedded" nodetree cases
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - this is like EVAL_ANIM_IDS, but this handles the case "embedded nodetrees"
* (i.e. scene/material/texture->nodetree) which we need a special exception
* for, otherwise they'd get skipped
* - ntp = "node tree parent" = datablock where node tree stuff resides
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
*/
#define EVAL_ANIM_NODETREE_IDS(first, NtId_Type, aflag) \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (id = first; id; id = id->next) { \
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
if (ID_REAL_USERS(id) > 0) { \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimData *adt = BKE_animdata_from_id(id); \
NtId_Type *ntp = (NtId_Type *)id; \
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
if (ntp->nodetree) { \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimData *adt2 = BKE_animdata_from_id((ID *)ntp->nodetree); \
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
BKE_animsys_evaluate_animdata(depsgraph, scene, (ID *)ntp->nodetree, adt2, ctime, ADT_RECALC_ANIM); \
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
} \
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
BKE_animsys_evaluate_animdata(depsgraph, scene, id, adt, ctime, aflag); \
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
} \
style cleanup: defines with braces
2012-05-27 20:13:59 +00:00
} (void)0
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* optimization:
* when there are no actions, don't go over database and loop over heaps of datablocks,
* which should ultimately be empty, since it is not possible for now to have any animation
2.5 - Animation Playback Tweaks * Added some optimisations to avoid having to try evaluating some data that won't have any effect. * Converted playback buttons in timeline header to use operators too
2009-08-02 11:05:13 +00:00
* without some actions, and drivers wouldn't get affected by any state changes
2.5 - Bugfix for curve-following animation not working Optimisation for not working with AnimData when there were no actions meant that the special hack to set this value didn't get set.
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
style cleanup - spelling - turns out we had tessellation spelt wrong all over. - use \directive for doxy (not @directive) - remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
2012-03-02 16:05:54 +00:00
* set correctly, so this optimization must be skipped in that case...
2.5 - Animation Playback Tweaks * Added some optimisations to avoid having to try evaluating some data that won't have any effect. * Converted playback buttons in timeline header to use operators too
2009-08-02 11:05:13 +00:00
*/
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
if (BLI_listbase_is_empty(&main->action) && BLI_listbase_is_empty(&main->curve)) {
move debug flag into its own global var (G.debug), split up debug options. --debug --debug-ffmpeg --debug-python --debug-events --debug-wm This makes debug output easier to read - event debug prints would flood output too much before. For convenience: --debug-all turns all debug flags on (works as --debug did before). also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
2012-03-31 00:59:17 +00:00
if (G.debug & G_DEBUG)
2.5 - Animation Playback Tweaks * Added some optimisations to avoid having to try evaluating some data that won't have any effect. * Converted playback buttons in timeline header to use operators too
2009-08-02 11:05:13 +00:00
printf("\tNo Actions, so no animation needs to be evaluated...\n");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Animation Playback Tweaks * Added some optimisations to avoid having to try evaluating some data that won't have any effect. * Converted playback buttons in timeline header to use operators too
2009-08-02 11:05:13 +00:00
return;
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* nodes */
2.5 - Animation Utility Function Added a utility function to check which transforms for an object or bone are animated, returning these as bitflags and/or optionally retrieving the relevant F-Curves too. Beware that this method may not be working correctly yet, but it shouldn't hurt anyone in the meantime :) Also, split RNA-path building function up into a version which only creates the path up to the given struct, with the other parts being added later.
2009-09-17 10:14:56 +00:00
EVAL_ANIM_IDS(main->nodetree.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
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 */
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
EVAL_ANIM_NODETREE_IDS(main->tex.first, Tex, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Cleanup: rename lamp -> light
2019-02-27 12:02:02 +11:00
/* lights */
DNA: rename Lamp -> Light - BKE_lamp -> BKE_light - Main.lamp -> light
2019-02-27 10:46:48 +11:00
EVAL_ANIM_NODETREE_IDS(main->light.first, Light, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
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 */
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
EVAL_ANIM_NODETREE_IDS(main->mat.first, Material, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* cameras */
2.5 - Added depsgraph tag for object-change in AnimData, so the new animsys doesn't have to all objects anymore. (Still WIP, depsgraph has to do this much better) - Bugfix in notifiers; only 1 notifier was handled for frame updates Result: 2 windows, displaying 2 scenes, now can be edited independently, and play independent. Not when they share data, of course. :)
2009-02-09 15:50:09 +00:00
EVAL_ANIM_IDS(main->camera.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* shapekeys */
2.5 - Added depsgraph tag for object-change in AnimData, so the new animsys doesn't have to all objects anymore. (Still WIP, depsgraph has to do this much better) - Bugfix in notifiers; only 1 notifier was handled for frame updates Result: 2 windows, displaying 2 scenes, now can be edited independently, and play independent. Not when they share data, of course. :)
2009-02-09 15:50:09 +00:00
EVAL_ANIM_IDS(main->key.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - MetaBalls are now animateable
2009-08-03 13:09:23 +00:00
/* metaballs */
EVAL_ANIM_IDS(main->mball.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* curves */
Changes to "evaluation time" for Curves: After discussions with Campbell regarding #24336 and #24309, we've decided to make this property for curves to only get set when an F-Curve explicitly animates it. As a consequence... - ALL OLD FILES using follow-path constraints that depended on this changed behaviour will currently need manual patching to add an appropriate F-Curve - Ctrl-P (Parenting to Curves -> Follow Path option) will now automatically create such F-Curves mimicking the old behaviour so that creating camera-following-path setups still works smoothly. - Directly adding a Follow Path constraint bypasses this, so you'll need to manually add such F-Curves if you need them. The main problem with the old approach was that there were many cases in which curve data could get added but the ctime would be incorrect until a frame change (i.e. on render) flushed this.
2010-10-21 10:28:06 +00:00
EVAL_ANIM_IDS(main->curve.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
* Added AnimData for Armature data, for animating armature/bone settings. This allows you to do funky things like animating the number of segments in a b-bone.
2009-09-21 06:43:20 +00:00
/* armatures */
EVAL_ANIM_IDS(main->armature.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Lattices now have AnimData This allows manual (point by point) animation of their control verts, although many other settings cannot really be animated with any visible effects yet. Interestingly, lattices also had IPO block pointers, though they were never really used (AFAIK). Todo: - Animation Editor support has yet to be added. I've got a few other things to add to, so will group those changes together.
2010-12-13 06:31:49 +00:00
/* lattices */
Cleanup: Main struct member names Rename latt to lattice and don't use plural names.
2019-02-27 11:14:41 +11:00
EVAL_ANIM_IDS(main->lattice.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* meshes */
Mesh Animation + Depsgraph Tweaks: * Mesh data/settings can now be animated. It is not recommended that geometry be animated directly, but other settings such as autosmooth, etc. can be... * Code cleanups for depsgraph, making sure that drivers get included for all object data types.
2009-12-28 00:52:31 +00:00
EVAL_ANIM_IDS(main->mesh.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Particle Settings now Animateable Added AnimData to ParticleSettings so that this will work. This seems to be ok in the brief tests I did, but be warned that this may not be optimal for the Particles System...
2009-06-24 02:11:36 +00:00
/* particles */
EVAL_ANIM_IDS(main->particle.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Depsgraph/Python: ensure datablocks with animation data get tagged as being updated on frame change.
2011-11-03 10:03:08 +00:00
/* speakers */
3D Audio GSoC: Adds new speaker object type. Notes: * Needs some nice icons * Quickily review by Joshua Leung (5 mins) * Properties UI updated (with help of Thomans Dinges) * Speakers have their own theme color * No real audio functionality yet. * Minor bug regarding lamps/lattices fixed in interface_templates.c I personality tested: * Creation, Deletion, Duplication * Saving, Loading * Library linking (incl. make local) * Tracking * Dope Sheet, Outliner * Animation * Drawing (incl. Theme)
2011-08-01 11:44:20 +00:00
EVAL_ANIM_IDS(main->speaker.first, ADT_RECALC_ANIM);
Camera tracking: animation datablock for MovieClip Added AnimData block to MovieClip datablock which allows to animate different properties in clip. Currently supports animation of stabilization influence only. -- svn merge -r44129:44130 ^/branches/soc-2011-tomato
2012-02-17 08:13:45 +00:00
/* movie clips */
EVAL_ANIM_IDS(main->movieclip.first, ADT_RECALC_ANIM);
A step toward a new user-friendly GUI for manipulating line style parameters. This commit is just meant to give the new GUI framework a concrete shape. There is no usefulness in newly introduced elements at the moment. Freestyle options in render layers now include a pull-down menu named Control Mode that allows you to choose either the Python Scripting or Parameter Editor mode. The Python Scripting mode is the conventional way of controlling Freestyle by directly using style modules written in Python. The Parameter Editor is a new control mode that is intended to be used by everyone without relying on Python programming. In the Parameter Editor mode, you can specify multiple line sets for each render layer. A line set defines feature edge selection criteria, as well as a line style for drawing the selected feature edges using specific line stylization parameters. Line style is a new datablock type, meaning that a line style can be shared by multiple line sets (possibly those in different render layers in different scenes). Much more additions are anticipated in subsequent commits to implement UI controls for specifying feature edge selection criteria and line stylization parameters.
2010-06-25 22:45:42 +00:00
/* linestyles */
EVAL_ANIM_IDS(main->linestyle.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
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 */
EVAL_ANIM_IDS(main->gpencil.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
New Grease Pencil object for 2D animation This commit merge the full development done in greasepencil-object branch and include mainly the following features. - New grease pencil object. - New drawing engine. - New grease pencil modes Draw/Sculpt/Edit and Weight Paint. - New brushes for grease pencil. - New modifiers for grease pencil. - New shaders FX. - New material system (replace old palettes and colors). - Split of annotations (old grease pencil) and new grease pencil object. - UI adapted to blender 2.8. You can get more info here: https://code.blender.org/2017/12/drawing-2d-animation-in-blender-2-8/ https://code.blender.org/2018/07/grease-pencil-status-update/ This is the result of nearly two years of development and I want thanks firstly the other members of the grease pencil team: Daniel M. Lara, Matias Mendiola and Joshua Leung for their support, ideas and to keep working in the project all the time, without them this project had been impossible. Also, I want thanks other Blender developers for their help, advices and to be there always to help me, and specially to Clément Foucault, Dalai Felinto, Pablo Vázquez and Campbell Barton.
2018-07-31 10:22:19 +02:00
/* palettes */
Cleanup: Main struct member names Rename latt to lattice and don't use plural names.
2019-02-27 11:14:41 +11:00
EVAL_ANIM_IDS(main->palette.first, ADT_RECALC_ANIM);
New Grease Pencil object for 2D animation This commit merge the full development done in greasepencil-object branch and include mainly the following features. - New grease pencil object. - New drawing engine. - New grease pencil modes Draw/Sculpt/Edit and Weight Paint. - New brushes for grease pencil. - New modifiers for grease pencil. - New shaders FX. - New material system (replace old palettes and colors). - Split of annotations (old grease pencil) and new grease pencil object. - UI adapted to blender 2.8. You can get more info here: https://code.blender.org/2017/12/drawing-2d-animation-in-blender-2-8/ https://code.blender.org/2018/07/grease-pencil-status-update/ This is the result of nearly two years of development and I want thanks firstly the other members of the grease pencil team: Daniel M. Lara, Matias Mendiola and Joshua Leung for their support, ideas and to keep working in the project all the time, without them this project had been impossible. Also, I want thanks other Blender developers for their help, advices and to be there always to help me, and specially to Clément Foucault, Dalai Felinto, Pablo Vázquez and Campbell Barton.
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 */
Cleanup: Main struct member names Rename latt to lattice and don't use plural names.
2019-02-27 11:14:41 +11:00
EVAL_ANIM_IDS(main->cachefile.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
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
/* objects */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
/* ADT_RECALC_ANIM doesn't need to be supplied here, since object AnimData gets
* this tagged by Depsgraph on framechange. This optimization means that objects
* linked from other (not-visible) scenes will not need their data calculated.
*/
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
EVAL_ANIM_IDS(main->object.first, 0);
mask mode for clip editor developed by Sergey Sharybin, Pete Larabell and myself. see: http://wiki.blender.org/index.php/User:Nazg-gul/MaskEditor note - mask editing tools need continued development, feather option is not working 100%
2012-06-04 16:42:58 +00:00
/* masks */
EVAL_ANIM_IDS(main->mask.first, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* worlds */
Nodes: add support for shader nodes on world and lamps, in addition to materials. The internal render engine does not support them, and they are not accesible in the UI yet, but cycles will use them.
2011-11-02 18:55:32 +00:00
EVAL_ANIM_NODETREE_IDS(main->world.first, World, ADT_RECALC_ANIM);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* scenes */
Partial fix for #24773: Material Nodes - there isn't able to set keys on Mapping coordinates Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is... TODO: animation editor support still to come
2010-11-22 23:59:00 +00:00
EVAL_ANIM_NODETREE_IDS(main->scene.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
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* ***************************************** */
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
/* ************** */
/* Evaluation API */
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
void BKE_animsys_eval_animdata(Depsgraph *depsgraph, ID *id)
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
{
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
float ctime = DEG_get_ctime(depsgraph);
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
AnimData *adt = BKE_animdata_from_id(id);
Scene *scene = NULL; /* XXX: this is only needed for flushing RNA updates,
Cleanup: Naming of depsgraph
2018-01-16 16:38:39 +01:00
* which should get handled as part of the dependency graph instead...
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
*/
Depsgraph: Allow per-depsgraph debug flags Currently only affects EVALUATION debug messages, rest are to be supported on per-depsgraph level.
2018-05-02 11:46:56 +02:00
DEG_debug_print_eval_time(depsgraph, __func__, id->name, id, ctime);
Fix T59495, T59992, T59904, T59178, T60598: broken keyframed value editing. This removes a bunch of animation/driver evaluations and recalc flags that should be redundant in the new depsgraph, and were incorrectly affecting the evaluated scene in a permanent way. Still two cases that could be removed if the depsgraph is improved, in BKE_object_handle_data_update and BKE_cachefile_update_frame. For physics subframe interpolation there are also still calls to BKE_object_where_is_calc that should ideally be removed as well, though they are not known to cause keyframing bugs. Differential Revision: https://developer.blender.org/D4274
2019-01-29 11:59:17 +01:00
BKE_animsys_evaluate_animdata(depsgraph, scene, id, adt, ctime, ADT_RECALC_ANIM);
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
}
Depsgraph: optimization of driver evaluation with many drivers.
2018-05-31 06:04:25 +02:00
void BKE_animsys_update_driver_array(ID *id)
Depsgraph: Fix missing updates with drivers The issue was only visible with copy-on-write enabled, and related to the fact, that dependency graph builder binds original FCurves. For now use smallest patch possible to make things to work and to make draguu happy. Need to think of a smarter way to deal with drivers, bones and view layers.
2018-03-14 15:19:44 +01:00
{
Depsgraph: optimization of driver evaluation with many drivers.
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);
Cleanup: whitespace
2018-06-01 18:10:43 +02:00
adt->driver_array = MEM_mallocN(sizeof(FCurve *) * num_drivers, "adt->driver_array");
Depsgraph: optimization of driver evaluation with many drivers.
2018-05-31 06:04:25 +02:00
int driver_index = 0;
for (FCurve *fcu = adt->drivers.first; fcu; fcu = fcu->next) {
adt->driver_array[driver_index++] = fcu;
}
Depsgraph: Fix missing updates with drivers The issue was only visible with copy-on-write enabled, and related to the fact, that dependency graph builder binds original FCurves. For now use smallest patch possible to make things to work and to make draguu happy. Need to think of a smarter way to deal with drivers, bones and view layers.
2018-03-14 15:19:44 +01:00
}
}
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
void BKE_animsys_eval_driver(Depsgraph *depsgraph,
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
ID *id,
Depsgraph: optimization of driver evaluation with many drivers.
2018-05-31 06:04:25 +02:00
int driver_index,
ChannelDriver *driver_orig)
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
{
/* TODO(sergey): De-duplicate with BKE animsys. */
PointerRNA id_ptr;
bool ok = false;
Depsgraph: optimization of driver evaluation with many drivers.
2018-05-31 06:04:25 +02:00
/* Lookup driver, accelerated with driver array map. */
const AnimData *adt = BKE_animdata_from_id(id);
Cleanup: whitespace
2018-06-01 18:10:43 +02:00
FCurve *fcu;
Depsgraph: optimization of driver evaluation with many drivers.
2018-05-31 06:04:25 +02:00
if (adt->driver_array) {
fcu = adt->driver_array[driver_index];
}
else {
fcu = BLI_findlink(&adt->drivers, driver_index);
}
Depsgraph: Fix missing updates with drivers The issue was only visible with copy-on-write enabled, and related to the fact, that dependency graph builder binds original FCurves. For now use smallest patch possible to make things to work and to make draguu happy. Need to think of a smarter way to deal with drivers, bones and view layers.
2018-03-14 15:19:44 +01:00
Depsgraph: Move evaluation debug prints to depsgraph This way we can easily control format and keep it consistent. And also possibly do other trickery, like coloring addresses!
2018-03-16 11:14:38 +01:00
DEG_debug_print_eval_subdata_index(
Depsgraph: Allow per-depsgraph debug flags Currently only affects EVALUATION debug messages, rest are to be supported on per-depsgraph level.
2018-05-02 11:46:56 +02:00
depsgraph, __func__, id->name, id, "fcu", fcu->rna_path, fcu, fcu->array_index);
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
RNA_id_pointer_create(id, &id_ptr);
/* 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! */
Fix T59495, T59992, T59904, T59178, T60598: broken keyframed value editing. This removes a bunch of animation/driver evaluations and recalc flags that should be redundant in the new depsgraph, and were incorrectly affecting the evaluated scene in a permanent way. Still two cases that could be removed if the depsgraph is improved, in BKE_object_handle_data_update and BKE_cachefile_update_frame. For physics subframe interpolation there are also still calls to BKE_object_where_is_calc that should ideally be removed as well, though they are not known to cause keyframing bugs. Differential Revision: https://developer.blender.org/D4274
2019-01-29 11:59:17 +01:00
if ((driver_orig) && !(driver_orig->flag & DRIVER_FLAG_INVALID)) {
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
/* evaluate this using values set already in other places
* 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 */
//printf("\told val = %f\n", fcu->curval);
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
PathResolvedRNA anim_rna;
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
if (animsys_store_rna_setting(&id_ptr, fcu->rna_path, fcu->array_index, &anim_rna)) {
Fix T59984: Drivers don't update values in UI or show proper errors We now perform COW -> original data flushing for all the debug values + error status flags on Drivers/DriverVariables/DriverTargets, as these are only set when errors are encountered when evaluating drivers.
2019-01-04 14:57:09 +13:00
/* Evaluate driver, and write results to COW-domain destination */
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
const float ctime = DEG_get_ctime(depsgraph);
Drivers: ensure Python expressions are cached with copy-on-write. Store the compiled expressions on the original driver. Ref T55442.
2018-06-11 20:00:03 +02:00
const float curval = evaluate_fcurve_driver(&anim_rna, fcu, driver_orig, ctime);
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
ok = animsys_write_rna_setting(&anim_rna, curval);
Fix T59984: Drivers don't update values in UI or show proper errors We now perform COW -> original data flushing for all the debug values + error status flags on Drivers/DriverVariables/DriverTargets, as these are only set when errors are encountered when evaluating drivers.
2019-01-04 14:57:09 +13:00
/* Flush results & status codes to original data for UI (T59984) */
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02:00
if (ok && DEG_is_active(depsgraph)) {
Remove AnimMapper: it has been left unimplemented for almost ten years. It was supposed to be a feature for substituting RNA paths on the fly, but has never been implemented, apart from a couple of structure definitions and passing around some always-NULL pointers. Now it gets in the way of refactoring NLA evaluation to use GHash for efficiency.
2018-11-12 19:30:25 +03:00
animsys_write_orig_anim_rna(&id_ptr, fcu->rna_path, fcu->array_index, curval);
Fix T59984: Drivers don't update values in UI or show proper errors We now perform COW -> original data flushing for all the debug values + error status flags on Drivers/DriverVariables/DriverTargets, as these are only set when errors are encountered when evaluating drivers.
2019-01-04 14:57:09 +13:00
/* curval is displayed in the UI, and flag contains error-status codes */
driver_orig->curval = fcu->driver->curval;
driver_orig->flag = fcu->driver->flag;
DriverVar *dvar_orig = driver_orig->variables.first;
DriverVar *dvar = fcu->driver->variables.first;
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;
}
dvar_orig->curval = dvar->curval;
dvar_orig->flag = dvar->flag;
}
Depsgraph: Copy evaluated data to original datablock Only do it for active dependency graph. Currently covers animation, drivers, object and pose channel matricies.
2018-05-31 14:27:37 +02:00
}
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
}
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
/* set error-flag if evaluation failed */
if (ok == 0) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "invalid driver - %s[%d]", fcu->rna_path, fcu->array_index);
Depsgraph: optimization of driver evaluation with many drivers.
2018-05-31 06:04:25 +02:00
driver_orig->flag |= DRIVER_FLAG_INVALID;
Depsgraph: Add evaluation callbacks for granular nodes update This commit only adds callbacks which then later be used with major dependency graph commit, keeping the upcoming commit more clean to follow. Should be no functional changes so far still.
2015-05-12 13:57:11 +05:00
}
}
}
}
Copy Permalink