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
d7708817d68617cb15d0690ebbd33a0fa090f4d2
blender-archive/source/blender/blenkernel/intern/anim_sys.c

2612 lines
82 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
* ***** BEGIN GPL LICENSE BLOCK *****
*
* 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.
*
* The Original Code is: all of this file.
*
* Contributor(s): Joshua Leung (full recode)
*
* ***** END GPL LICENSE BLOCK *****
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: blender/blenkernel tagged.
2011-02-27 20:40:57 +00:00
/** \file blender/blenkernel/intern/anim_sys.c
* \ingroup bke
*/
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"
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
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
#include "BLF_translation.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 "DNA_anim_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_lamp_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"
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: 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_animsys.h"
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"
Depsgraph/Python: ensure datablocks with animation data get tagged as being updated on frame change.
2011-11-03 10:03:08 +00:00
#include "BKE_depsgraph.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"
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
#include "BKE_nla.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"
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"
split BKE_utildefines.h, now it only has blender specific defines like GS() MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h. no functional changes.
2011-01-07 18:36:47 +00:00
#include "BKE_library.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"
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
/* ***************************************** */
/* 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 */
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
bool id_type_can_have_animdata(ID *id)
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 check */
if (id == NULL)
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 0;
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +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 */
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
switch (GS(id->name)) {
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:
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:
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
return 1;
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
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:
return 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
}
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
}
/* Get AnimData from the given ID-block. In order for this to work, we assume that
* 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
{
/* only some ID-blocks have this info for now, so we cast the
* types that do to be of type IdAdtTemplate, and extract the
* AnimData that way
*/
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
if (id_type_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
}
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
/* Add AnimData to the given ID-block. In order for this to work, we assume that
* the AnimData pointer is stored immediately after the given ID-block in the struct,
* as per IdAdtTemplate. Also note that
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimData *BKE_id_add_animdata(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
{
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, so we cast the
* types that do to be of type IdAdtTemplate, and add the AnimData
* to it using the template
*/
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
if (id_type_can_have_animdata(id)) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
IdAdtTemplate *iat = (IdAdtTemplate *)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
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;
/* add animdata */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
adt = iat->adt = MEM_callocN(sizeof(AnimData), "AnimData");
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
}
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
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;
}
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;
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;
}
/* active action is only editable when it is not a tweaking strip
* 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;
}
/* 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);
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);
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
ok = 1;
}
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);
/* ok = 0; */
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;
ok = 1;
}
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 */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_free_animdata(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
{
/* Only some ID-blocks have this info for now, so we cast the
* 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
*/
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
if (id_type_can_have_animdata(id)) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
IdAdtTemplate *iat = (IdAdtTemplate *)id;
AnimData *adt = iat->adt;
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) {
/* unlink action (don't free, as it's in its own list) */
if (adt->action)
adt->action->id.us--;
NLA SoC: Operators for 'tweaking' strip actions (TAB-Key for both) In this commit, I've introduced the mechanism by which actions already referenced by strips used in the NLA can be edited (or 'tweaked'). To use, simply select a strip you wish to edit, and hit that TAB key to start tweaking that strip's action, and hit TAB again once you're done. What happens when you enter 'tweak mode': 1) The action of the active strip temporarily becomes the 'active action' of the AnimData block. You are now able to edit this in one of the Animation Editors (DopeSheet/Action, Graph Editors) as per normal (i.e. sliding keyframes around, inserting keyframes, etc.). The 'action-line' will therefore get drawn immediately above the active track containing the active strip, so that it's clear that that's what we're editing. 2) All the NLA-tracks (and all the strips within them) that occur after the track that the active strip lived in get disabled while you're in tweakmode. This is equivalent to travelling back to an earlier state in a construction history stack. 3) The active NLA track also gets disabled while in tweakmode, since it would otherwise interfere with the correct functioning of the tweaking for the action of interest. 4) The 'real' active action (i.e. the one displaced by the active strip's action) gets put into temp storage, and will be restored after you exit tweakmode. 5) Any strips which also reference the action being tweaked will get highlighted in red shading to indicate that you may be making some changes to the action which you don't really want to make for the other users too. Please note though, that this is only a rough prototype of this functionality, with some niceties still to come. i.e.: * NLA-tracks after the active track should still get drawn above the 'tweaking action line', but perhaps with different appearance? * Various tools will still need awareness of this to prevent corrupting operations from taking place. How to proceed is still undecided... * When exiting tweak-mode, the strip the action came from still needs some form of syncing with the modified action... there are a few tricky issues here that will need to be solved * Evaluation code doesn't totally take this into account yet... --- Also, fixed a number of bugs with various code (notably selection, and also a few drawing bugs)
2009-06-05 05:18:07 +00:00
/* same goes for the temporarily displaced action */
if (adt->tmpact)
adt->tmpact->id.us--;
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
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 */
free_nladata(&adt->nla_tracks);
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);
/* free overrides */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO... */
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
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
}
}
}
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 -------------------------------------------- */
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
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 the given AnimData - to be used when copying datablocks */
patch [#34103] check_for_dupid.patch from Lawrence D'Oliveiro (ldo) - more comments - more uses of bool type - define symbol for length of in_use array in check_for_dupid
2013-03-10 05:46:24 +00:00
AnimData *BKE_copy_animdata(AnimData *adt, const bool do_action)
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;
/* 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);
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) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
dadt->action = BKE_action_copy(adt->action);
dadt->tmpact = BKE_action_copy(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
}
else {
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 */
NLA SoC: Adding more backend code/utilities * Data copying * Strip sorting
2009-05-23 09:36:18 +00:00
copy_nladata(&dadt->nla_tracks, &adt->nla_tracks);
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);
/* 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);
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
}
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
bool BKE_copy_animdata_id(ID *id_to, ID *id_from, const bool do_action)
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)))
Make linked animdata working again, copies NLA too, as well as ObData animdata where types match
2010-01-10 20:23:59 +00:00
return 0;
BKE_free_animdata(id_to);
adt = BKE_animdata_from_id(id_from);
if (adt) {
IdAdtTemplate *iat = (IdAdtTemplate *)id_to;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
iat->adt = BKE_copy_animdata(adt, do_action);
Make linked animdata working again, copies NLA too, as well as ObData animdata where types match
2010-01-10 20:23:59 +00:00
}
return 1;
}
Bugfix [#28267] keyframed values for shapekeys of copied objects are linked Shapekey actions weren't getting copied when their owner data was. This was due to the IMO totally convoluted way in which the duplicate action flags have been set up: - the function to copy animdata takes a param to specify whether actions are copied or not, but this is never touched (i.e. this always just gets FALSE passed in) - instead, we jump around in hoops later figuring out whether the userpref wants copying to occur, then fixing up the links IIRC, part of this may be due to a desire/need to not duplicate actions when dealing with NodeTree copies for multi-threaded rendering, but at the expense of complicating everything else.
2011-08-16 01:02:26 +00:00
void BKE_copy_animdata_id_action(ID *id)
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);
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
adt->action = BKE_action_copy(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);
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
adt->tmpact = BKE_action_copy(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
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
/* Make Local -------------------------------------------- */
static void make_local_strips(ListBase *strips)
{
NlaStrip *strip;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (strip = strips->first; strip; strip = strip->next) {
code cleanup: function naming, use BKE_*type* prefix.
2012-05-05 14:03:12 +00:00
if (strip->act) BKE_action_make_local(strip->act);
if (strip->remap && strip->remap->target) BKE_action_make_local(strip->remap->target);
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
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
make_local_strips(&strip->strips);
}
}
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
/* Use local copy instead of linked copy of various ID-blocks */
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
void BKE_animdata_make_local(AnimData *adt)
{
NlaTrack *nlt;
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
/* Actions - Active and Temp */
code cleanup: function naming, use BKE_*type* prefix.
2012-05-05 14:03:12 +00:00
if (adt->action) BKE_action_make_local(adt->action);
if (adt->tmpact) BKE_action_make_local(adt->tmpact);
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
/* Remaps */
code cleanup: function naming, use BKE_*type* prefix.
2012-05-05 14:03:12 +00:00
if (adt->remap && adt->remap->target) BKE_action_make_local(adt->remap->target);
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 */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: need to remap the ID-targets too? */
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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (nlt = adt->nla_tracks.first; nlt; nlt = nlt->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
make_local_strips(&nlt->strips);
}
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
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
/* When duplicating data (i.e. objects), drivers referring to the original data will
* get updated to point to the duplicated data (if drivers belong to the new data)
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_relink_animdata(AnimData *adt)
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
{
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
/* sanity check */
if (adt == NULL)
return;
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
/* drivers */
if (adt->drivers.first) {
FCurve *fcu;
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
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
/* check each driver against all the base paths to see if any should go */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (fcu = adt->drivers.first; fcu; fcu = fcu->next) {
ChannelDriver *driver = fcu->driver;
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
DriverVar *dvar;
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
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
/* driver variables */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (dvar = driver->variables.first; dvar; dvar = dvar->next) {
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
/* only change the used targets, since the others will need fixing manually anyway */
DRIVER_TARGETS_USED_LOOPER(dvar)
{
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
if (dtar->id && dtar->id->newid) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
dtar->id = dtar->id->newid;
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
}
}
DRIVER_TARGETS_LOOPER_END
}
}
}
}
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 ------------------------------------------- */
/* helper heuristic for determining if a path is compatible with the basepath
* < path: (str) full RNA-path from some data (usually an F-Curve) to compare
* < basepath: (str) shorter path fragment to look for
* > returns (bool) whether there is a match
*/
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
}
/* Move F-Curves in src action to dst action, setting up all the necessary groups
* for this to happen, but only if the F-Curves being moved have the appropriate
* "base path".
* - This is used when data moves from one datablock to another, causing the
* F-Curves to need to be moved over too
*/
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;
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 (ELEM3(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) {
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
printf("ERROR: action_partition_fcurves_by_basepath(%p, %p, %p) has insufficient info to work with\n",
style cleanup: whitespace
2012-05-12 16:11:34 +00: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;
}
/* clear 'temp' flags on all groups in src, as we'll be needing them later
* to identify groups that we've managed to empty out here
*/
action_groups_clear_tempflags(srcAct);
/* 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;
/* should F-Curve be moved over?
* - we only need the start of the path to match basepath
*/
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;
/* 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);
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);
}
/* 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;
}
/* perform the migration now */
action_groups_remove_channel(srcAct, fcu);
if (agrp)
action_groups_add_channel(dstAct, agrp, fcu);
else
BLI_addtail(&dstAct->curves, fcu);
}
}
/* cleanup groups (if present) */
if (srcAct->groups.first) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
bActionGroup *agrp, *grp = 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
for (agrp = srcAct->groups.first; agrp; agrp = grp) {
grp = agrp->next;
/* 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
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_animdata_separate_by_basepath(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;
/* 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)
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
printf("ERROR: no source or destination ID to separate AnimData with\n");
return;
}
/* get animdata from src, and create for destination (if needed) */
srcAdt = BKE_animdata_from_id(srcID);
dstAdt = BKE_id_add_animdata(dstID);
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)
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
printf("ERROR: no AnimData for this pair of ID's\n");
return;
}
/* 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) {
Fix #34040: Moving Normal Node with enabled Cycles Material Preview crashes Issue was caused by couple of circumstances: - Normal Map node requires tesselated faces to compute tangent space - All temporary meshes needed for Cycles export were adding to G.main - Undo pushes would temporary set meshes tessfaces to NULL - Moving node will cause undo push and tree re-evaluate fr preview All this leads to threading conflict between preview render and undo system. Solved it in way that all temporary meshes are adding to that exact Main which was passed to Cycles via BlendData. This required couple of mechanic changes like adding extra parameter to *_add() functions and adding some *_ex() functions to make it possible RNA adds objects to Main passed to new() RNA function. This was tricky to pass Main to RNA function and IMO that's not so nice to pass main to function, so ended up with such decision: - Object.to_mesh() will add temp mesh to G.main - Added Main.meshes.new_from_object() which does the same as to_mesh, but adds temporary mesh to specified Main. So now all temporary meshes needed for preview render would be added to preview_main which does not conflict with undo pushes. Viewport render shall not be an issue because object sync happens from main thread in this case. It could be some issues with final render, but that's not so much likely to happen, so shall be fine. Thanks to Brecht for review!
2013-02-05 12:46:15 +00:00
dstAdt->action = add_empty_action(G.main, 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) {
printf("Argh! Source and Destination share animation! ('%s' and '%s' both use '%s') Making new empty action\n",
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
srcID->name, dstID->name, srcAdt->action->id.name);
Whitespace
2013-01-29 01:23:29 +00: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);
Fix #34040: Moving Normal Node with enabled Cycles Material Preview crashes Issue was caused by couple of circumstances: - Normal Map node requires tesselated faces to compute tangent space - All temporary meshes needed for Cycles export were adding to G.main - Undo pushes would temporary set meshes tessfaces to NULL - Moving node will cause undo push and tree re-evaluate fr preview All this leads to threading conflict between preview render and undo system. Solved it in way that all temporary meshes are adding to that exact Main which was passed to Cycles via BlendData. This required couple of mechanic changes like adding extra parameter to *_add() functions and adding some *_ex() functions to make it possible RNA adds objects to Main passed to new() RNA function. This was tricky to pass Main to RNA function and IMO that's not so nice to pass main to function, so ended up with such decision: - Object.to_mesh() will add temp mesh to G.main - Added Main.meshes.new_from_object() which does the same as to_mesh, but adds temporary mesh to specified Main. So now all temporary meshes needed for preview render would be added to preview_main which does not conflict with undo pushes. Viewport render shall not be an issue because object sync happens from main thread in this case. It could be some issues with final render, but that's not so much likely to happen, so shall be fine. Thanks to Brecht for review!
2013-02-05 12:46:15 +00:00
dstAdt->action = add_empty_action(G.main, 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
}
/* 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);
}
}
/* drivers */
if (srcAdt->drivers.first) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
FCurve *fcu, *fcn = 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
/* 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;
/* 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;
if (animpath_matches_basepath(fcu->rna_path, basepath)) {
/* just need to change lists */
BLI_remlink(&srcAdt->drivers, fcu);
BLI_addtail(&dstAdt->drivers, fcu);
Whitespace
2013-01-29 01:23:29 +00:00
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: add depsgraph flushing calls? */
Whitespace
2013-01-29 01:23:29 +00: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
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;
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);
/* try to resolve */
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
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
}
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
/* 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);
2.5 - Assorted Animation UI/Editing Tweaks Main Feature: * It is now possible to choose which AnimData block is the 'active' one for editing, and/or select them too. AnimData blocks are generally the dark blue and lighter-blue expanders (i.e. Scene, Object, Camera, Lamp, Curve, Armature, etc.) * Objects are no longer selected/deselected when AKEY is used to toggle selection of channels. This was getting a bit annoying. * Following on from selection of AnimData blocks, it is now possible to select/make active an AnimData block in the animation editors, and change the active action for that block via the 'Animation Data' panel in NLA Editor's properties region. --> Be aware that user-counts are not totally handled correctly there yet, so some funky behaviour might be seen... --> It is possible to assign a new action, or to assign an existing one, allowing to switch between actions as in the past with Actions/IPO Editors... Other tweaks: * Some code tweaks towards making the 'Euler Filter' feature for Graph Editor working sometime soon * Added some backend code for snapping the values of keyframes to a single value. Still need to work out some UI for it though. * Shuffled the code for ACT_OT_new() around, and removed the poll() callback so that it worked in NLA too. * Fixed some more notifier bugs with deleting bones and a few other editmode operations for Armatures.
2009-09-27 04:22:04 +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
/* 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;
char oldChar;
/* add the part of the string that goes up to the start of the prefix */
if (prefixPtr > oldpath) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
oldChar = prefixPtr[0];
prefixPtr[0] = 0;
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_append(ds, oldpath);
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
prefixPtr[0] = oldChar;
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);
/* add the new name (complete with brackets) */
BLI_dynstr_append(ds, newName);
/* add the postfix */
BLI_dynstr_append(ds, postfixPtr);
/* 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);
/* 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
}
}
2.5 - Assorted Animation UI/Editing Tweaks Main Feature: * It is now possible to choose which AnimData block is the 'active' one for editing, and/or select them too. AnimData blocks are generally the dark blue and lighter-blue expanders (i.e. Scene, Object, Camera, Lamp, Curve, Armature, etc.) * Objects are no longer selected/deselected when AKEY is used to toggle selection of channels. This was getting a bit annoying. * Following on from selection of AnimData blocks, it is now possible to select/make active an AnimData block in the animation editors, and change the active action for that block via the 'Animation Data' panel in NLA Editor's properties region. --> Be aware that user-counts are not totally handled correctly there yet, so some funky behaviour might be seen... --> It is possible to assign a new action, or to assign an existing one, allowing to switch between actions as in the past with Actions/IPO Editors... Other tweaks: * Some code tweaks towards making the 'Euler Filter' feature for Graph Editor working sometime soon * Added some backend code for snapping the values of keyframes to a single value. Still need to work out some UI for it though. * Shuffled the code for ACT_OT_new() around, and removed the poll() callback so that it worked in NLA too. * Fixed some more notifier bugs with deleting bones and a few other editmode operations for Armatures.
2009-09-27 04:22:04 +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
/* 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 */
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
static void 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;
/* 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) {
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
if (fcu->rna_path) {
Code cleanup: use 'const' for arrays (blenkernel)
2014-04-27 00:20:13 +10:00
const char *old_path = fcu->rna_path;
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
/* 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;
style cleanup: also correct incorrect doxy heading
2012-09-26 20:26:31 +00:00
if ((agrp) && strcmp(oldName, agrp->name) == 0) {
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
BLI_strncpy(agrp->name, newName, sizeof(agrp->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
}
}
/* Check RNA-Paths for a list of Drivers */
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
static void 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
{
FCurve *fcu;
/* 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 */
if (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);
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
/* driver? */
if (fcu->driver) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ChannelDriver *driver = fcu->driver;
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
DriverVar *dvar;
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
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
/* driver variables */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (dvar = driver->variables.first; dvar; dvar = dvar->next) {
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* only change the used targets, since the others will need fixing manually anyway */
DRIVER_TARGETS_USED_LOOPER(dvar)
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
{
/* rename RNA path */
fix [#26507] Rename bone -> segfault
2011-03-15 03:38:15 +00:00
if (dtar->rna_path && dtar->id)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
dtar->rna_path = rna_path_rename_fix(dtar->id, prefix, oldKey, newKey, dtar->rna_path, verify_paths);
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
/* also fix the bone-name (if applicable) */
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 (strstr(prefix, "bones")) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ( ((dtar->id) && (GS(dtar->id->name) == ID_OB) && (!ref_id || ((Object *)(dtar->id))->data == ref_id)) &&
(dtar->pchan_name[0]) && (strcmp(oldName, dtar->pchan_name) == 0) )
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
{
BLI_strncpy(dtar->pchan_name, newName, sizeof(dtar->pchan_name));
}
}
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
}
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 all RNA-Paths for Actions linked to NLA Strips */
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
static void 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;
/* 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 */
if (strip->act)
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
fcurves_path_rename_fix(owner_id, prefix, oldName, newName, oldKey, newKey, &strip->act->curves, 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
/* ignore own F-Curves, since those are local... */
/* check sub-strips (if metas) */
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
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
}
}
Bugfix: Renaming bones now renames the corresponding F-Curves in actions used by Action Constraints
2013-10-22 11:36:48 +00:00
/* Fix all RNA_Paths in the given Action, relative to the given ID block
*
* 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;
/* if no action, no need to proceed */
if (ELEM(NULL, owner_id, act))
return;
/* 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);
}
/* fix paths in action */
fcurves_path_rename_fix(owner_id, prefix, oldName, newName, oldN, newN, &act->curves, verify_paths);
/* 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;
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
/* if no AnimData, no need to proceed */
Fix [#21165] Moved textures don't move the animation curves
2010-03-16 07:44:57 +00:00
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;
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 - 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 [#21165] Moved textures don't move the animation curves
2010-03-16 07:44:57 +00: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
}
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
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
/* Active action and temp action */
if (adt->action)
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
fcurves_path_rename_fix(owner_id, prefix, oldName, newName, oldN, newN, &adt->action->curves, 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
if (adt->tmpact)
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
fcurves_path_rename_fix(owner_id, prefix, oldName, newName, oldN, newN, &adt->tmpact->curves, 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
/* Drivers - Drivers are really F-Curves */
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
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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (nlt = adt->nla_tracks.first; nlt; nlt = nlt->next)
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
nlastrips_path_rename_fix(owner_id, prefix, oldName, newName, oldN, newN, &nlt->strips, verify_paths);
fix [#34958] keyframe many items would fail if there was a (") in the text.
2013-04-23 20:10:22 +00:00
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
}
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
/* *************************** */
/* remove of individual paths */
/* Check RNA-Paths for a list of F-Curves */
static void fcurves_path_remove_fix(const char *prefix, ListBase *curves)
{
FCurve *fcu, *fcn;
if (!prefix) return;
/* 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);
}
}
}
}
/* Check RNA-Paths for a list of F-Curves */
static void nlastrips_path_remove_fix(const char *prefix, ListBase *strips)
{
NlaStrip *strip;
/* recursively check strips, fixing only actions... */
for (strip = strips->first; strip; strip = strip->next) {
/* fix strip's action */
if (strip->act)
fcurves_path_remove_fix(prefix, &strip->act->curves);
/* check sub-strips (if metas) */
nlastrips_path_remove_fix(prefix, &strip->strips);
}
}
void BKE_animdata_fix_paths_remove(ID *id, const char *prefix)
{
/* Only some ID-blocks have this info for now, so we cast the
* types that do to be of type IdAdtTemplate
*/
NlaTrack *nlt;
if (id_type_can_have_animdata(id)) {
IdAdtTemplate *iat = (IdAdtTemplate *)id;
AnimData *adt = iat->adt;
/* check if there's any AnimData to start with */
if (adt) {
/* free fcurves */
if (adt->action)
fcurves_path_remove_fix(prefix, &adt->action->curves);
if (adt->tmpact)
fcurves_path_remove_fix(prefix, &adt->tmpact->curves);
/* free drivers - stored as a list of F-Curves */
fcurves_path_remove_fix(prefix, &adt->drivers);
/* NLA Data - Animation Data for Strips */
for (nlt = adt->nla_tracks.first; nlt; nlt = nlt->next)
nlastrips_path_remove_fix(prefix, &nlt->strips);
}
}
}
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 */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_animdata_main_cb(Main *mainptr, 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
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
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
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
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 */
ANIMDATA_IDS_CB(mainptr->nodetree.first);
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
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 */
ANIMDATA_NODETREE_IDS_CB(mainptr->tex.first, Tex);
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
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
/* lamps */
Fix #33123: lamp nodes drivers not working, now uses same hacks as material to work around dependency graph limitations.
2012-11-09 13:57:09 +00:00
ANIMDATA_NODETREE_IDS_CB(mainptr->lamp.first, Lamp);
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 */
ANIMDATA_NODETREE_IDS_CB(mainptr->mat.first, Material);
/* cameras */
ANIMDATA_IDS_CB(mainptr->camera.first);
/* shapekeys */
ANIMDATA_IDS_CB(mainptr->key.first);
/* metaballs */
ANIMDATA_IDS_CB(mainptr->mball.first);
/* curves */
ANIMDATA_IDS_CB(mainptr->curve.first);
/* armatures */
ANIMDATA_IDS_CB(mainptr->armature.first);
/* lattices */
ANIMDATA_IDS_CB(mainptr->latt.first);
/* meshes */
ANIMDATA_IDS_CB(mainptr->mesh.first);
/* particles */
ANIMDATA_IDS_CB(mainptr->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 */
ANIMDATA_IDS_CB(mainptr->speaker.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
/* movie clips */
ANIMDATA_IDS_CB(mainptr->movieclip.first);
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 */
ANIMDATA_IDS_CB(mainptr->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 */
ANIMDATA_IDS_CB(mainptr->mask.first);
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 */
Fix #33123: lamp nodes drivers not working, now uses same hacks as material to work around dependency graph limitations.
2012-11-09 13:57:09 +00:00
ANIMDATA_NODETREE_IDS_CB(mainptr->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 */
ANIMDATA_NODETREE_IDS_CB(mainptr->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 */
ANIMDATA_IDS_CB(mainptr->linestyle.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 */
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_all_animdata_fix_paths_rename(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
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
Main *mainptr = G.main;
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;
/* macro for less typing
* - whether animdata exists is checked for by the main renaming callback, though taking
* this outside of the function may make things slightly faster?
*/
#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
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
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) { \
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimData *adt2 = BKE_animdata_from_id((ID *)ntp); \
BKE_animdata_fix_paths_rename((ID *)ntp, 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
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
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 */
RENAMEFIX_ANIM_IDS(mainptr->nodetree.first);
/* textures */
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
RENAMEFIX_ANIM_NODETREE_IDS(mainptr->tex.first, Tex);
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
/* lamps */
Fix #33123: lamp nodes drivers not working, now uses same hacks as material to work around dependency graph limitations.
2012-11-09 13:57:09 +00:00
RENAMEFIX_ANIM_NODETREE_IDS(mainptr->lamp.first, Lamp);
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 */
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
RENAMEFIX_ANIM_NODETREE_IDS(mainptr->mat.first, Material);
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 */
RENAMEFIX_ANIM_IDS(mainptr->camera.first);
/* shapekeys */
RENAMEFIX_ANIM_IDS(mainptr->key.first);
/* metaballs */
RENAMEFIX_ANIM_IDS(mainptr->mball.first);
/* curves */
RENAMEFIX_ANIM_IDS(mainptr->curve.first);
/* armatures */
RENAMEFIX_ANIM_IDS(mainptr->armature.first);
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 */
RENAMEFIX_ANIM_IDS(mainptr->latt.first);
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 */
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
RENAMEFIX_ANIM_IDS(mainptr->mesh.first);
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 */
RENAMEFIX_ANIM_IDS(mainptr->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 */
RENAMEFIX_ANIM_IDS(mainptr->speaker.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
/* movie clips */
RENAMEFIX_ANIM_IDS(mainptr->movieclip.first);
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 */
RENAMEFIX_ANIM_IDS(mainptr->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 */
RENAMEFIX_ANIM_IDS(mainptr->mask.first);
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 */
Fix #33123: lamp nodes drivers not working, now uses same hacks as material to work around dependency graph limitations.
2012-11-09 13:57:09 +00:00
RENAMEFIX_ANIM_NODETREE_IDS(mainptr->world.first, World);
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
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 */
RENAMEFIX_ANIM_IDS(mainptr->linestyle.first);
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 */
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
RENAMEFIX_ANIM_NODETREE_IDS(mainptr->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
}
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;
/* 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 (ELEM3(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;
/* loop over paths in the current KeyingSet, finding the first one where all settings match
* (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;
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;
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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ((ksp->rna_path == NULL) || strcmp(rna_path, ksp->rna_path))
eq_path = 0;
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
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;
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
}
/* if all aspects are ok, return */
if (eq_id && eq_path && eq_index && eq_group)
return ksp;
}
/* none found */
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
/* 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;
/* 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;
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);
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));
Fixing several issues with keyingsets: *Add a new idname to keyingsets, keeping name as label-only (using same string for both made lookup fail when using i18n other than english, as it tried to compare an untranslated static string id against a translated RNA name). Also adding a description string (can be helpful with custom keyingsets, imho). *Fixed a few other bugs related to that area (namely, you can’t deselect current keyingset from the shift-ctrl-alt-I popup menu, and insert/delete key ops were using a rather strange way to get chosen custom keyingset…). *Fixed UI code so that it always uses (RNA) enum, and simplified menu-creation code.
2012-03-08 14:04:06 +00: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));
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
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;
/* 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)) {
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
printf("ERROR: no Keying Set and/or RNA Path to add path with\n");
== 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
}
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
/* 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) {
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
printf("ERROR: No ID provided for Keying Set Path\n");
== 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
}
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)
printf("ERROR: destination already exists in Keying Set\n");
== 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
}
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
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");
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';
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
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);
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
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? */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ksp->rna_path = BLI_strdupn(rna_path, strlen(rna_path));
ksp->array_index = array_index;
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;
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);
== 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;
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 */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_keyingsets_copy(ListBase *newlist, 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;
== 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
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);
== 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
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;
/* sanity check */
if (ks == NULL)
return;
/* 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;
/* sanity check */
if (list == NULL)
return;
/* loop over KeyingSets freeing them
style cleanup: whitespace
2012-05-12 16:11:34 +00: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 */
/* Retrieve string to act as RNA-path, adjusted using mapping-table if provided
* It returns whether the string needs to be freed (i.e. if it was a temp remapped one)
* // FIXME: maybe it would be faster if we didn't have to alloc/free strings like this all the time, but for now it's safer
*
* - remap: remapping table to use
* - path: original path string (as stored in F-Curve data)
* - dst: destination string to write data to
*/
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
static bool animsys_remap_path(AnimMapper *UNUSED(remap), char *path, char **dst)
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
{
/* is there a valid remapping table to use? */
style cleanup
2012-07-07 22:51:57 +00:00
#if 0
if (remap) {
/* find a matching entry... to use to remap */
/* ...TODO... */
}
#endif
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
/* nothing suitable found, so just set dst to look at path (i.e. no alloc/free needed) */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
*dst = path;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
return 0;
}
fcurve/boolean evaluation, values below zero are no longer evaluated to true.
2011-05-26 05:35:30 +00:00
/* less then 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
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 */
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
static bool animsys_write_rna_setting(PointerRNA *ptr, char *path, int array_index, 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
{
PropertyRNA *prop;
PointerRNA new_ptr;
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
//printf("%p %s %i %f\n", ptr, path, array_index, 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
/* get property to write to */
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
if (RNA_path_resolve_property(ptr, path, &new_ptr, &prop)) {
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
/* set value - only for animatable numerical values */
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
if (RNA_property_animateable(&new_ptr, prop)) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
int array_len = RNA_property_array_length(&new_ptr, prop);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
bool written = false;
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
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
if (array_len && array_index >= array_len) {
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("Animato: Invalid array index. ID = '%s', '%s[%d]', array length is %d\n",
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
(ptr && ptr->id.data) ? (((ID *)ptr->id.data)->name + 2) : "<No ID>",
path, array_index, array_len - 1);
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
}
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
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
return 0;
}
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
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
switch (RNA_property_type(prop)) {
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 PROP_BOOLEAN:
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
if (array_len) {
if (RNA_property_boolean_get_index(&new_ptr, prop, array_index) != ANIMSYS_FLOAT_AS_BOOL(value)) {
RNA_property_boolean_set_index(&new_ptr, prop, array_index, ANIMSYS_FLOAT_AS_BOOL(value));
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
written = true;
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
}
}
else {
if (RNA_property_boolean_get(&new_ptr, prop) != ANIMSYS_FLOAT_AS_BOOL(value)) {
RNA_property_boolean_set(&new_ptr, prop, ANIMSYS_FLOAT_AS_BOOL(value));
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
written = true;
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +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
break;
case PROP_INT:
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
if (array_len) {
if (RNA_property_int_get_index(&new_ptr, prop, array_index) != (int)value) {
RNA_property_int_set_index(&new_ptr, prop, array_index, (int)value);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
written = true;
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
}
}
else {
if (RNA_property_int_get(&new_ptr, prop) != (int)value) {
RNA_property_int_set(&new_ptr, prop, (int)value);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
written = true;
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +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
break;
case PROP_FLOAT:
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
if (array_len) {
if (RNA_property_float_get_index(&new_ptr, prop, array_index) != value) {
RNA_property_float_set_index(&new_ptr, prop, array_index, value);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
written = true;
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
}
}
else {
if (RNA_property_float_get(&new_ptr, prop) != value) {
RNA_property_float_set(&new_ptr, prop, value);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
written = true;
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +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
break;
case PROP_ENUM:
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
if (RNA_property_enum_get(&new_ptr, prop) != (int)value) {
RNA_property_enum_set(&new_ptr, prop, (int)value);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
written = true;
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +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
break;
default:
Drivers: "Scripted Expression" drivers (i.e. PyDrivers) work again Now it is possible to write a Python Expression using the variable names for driver targets (see mockup from initial commit) to substitute the appropriate values into the expression. In the __global__ namespace for PyDriver evaluation, the following modules are available: * __builtins__ - i.e. the builtin Python functions * bpy - new Python API * math or m - math module For example: Consider a driver with three targets, named: A, B, C Now, you could write an expression like: C if A < 5 else B or even: 2*C if A < 5 or A > 20 else m.PI*B Of course, you don't have to have three targets, the above was just an example. TODO: * Bring back way to load pydrivers.py * Blender.Noise equivalent would be nice to have P.S. I hope I haven't made any terrible Python API coding errors here (i.e. mem leaks, etc.)
2009-04-20 09:17:43 +00:00
/* nothing can be done here... so it is unsuccessful? */
return 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
}
== 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
Bugfixes for: [#28525] [#28690] [#28774] [#28777] This commit basically disables the RNA update caches for now, and introduces a workaround/hack to ensure that modifier properties still work when animated/driven. The whole way that updates currently get handled needs reviewing in future. Fix provided by Brecht.
2011-10-01 01:27:44 +00:00
/* RNA property update disabled for now - [#28525] [#28690] [#28774] [#28777] */
#if 0
== 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
/* buffer property update for later flushing */
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
if (written && RNA_property_update_check(prop)) {
== 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
short skip_updates_hack = 0;
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
/* optimization hacks: skip property updates for those properties
== 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
* for we know that which the updates in RNA were really just for
* flushing property editing via UI/Py
*/
Assorted comment clarification in response to code review notes
2011-08-28 11:39:18 +00:00
if (new_ptr.type == &RNA_PoseBone) {
== 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
/* bone transforms - update pose (i.e. tag depsgraph) */
skip_updates_hack = 1;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00: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
if (skip_updates_hack == 0)
RNA_property_update_cache_add(&new_ptr, prop);
}
Bugfixes for: [#28525] [#28690] [#28774] [#28777] This commit basically disables the RNA update caches for now, and introduces a workaround/hack to ensure that modifier properties still work when animated/driven. The whole way that updates currently get handled needs reviewing in future. Fix provided by Brecht.
2011-10-01 01:27:44 +00:00
#endif
Depsgraph/Python: ensure datablocks with animation data get tagged as being updated on frame change.
2011-11-03 10:03:08 +00:00
/* as long as we don't do property update, we still tag datablock
style cleanup / comment formatting for bli/bke/bmesh
2012-03-03 20:19:11 +00:00
* as having been updated. this flag does not cause any updates to
* be run, it's for e.g. render engines to synchronize data */
Fix cycles continuously updating when creating a driver for a scene property, like driving integrator seed with #frame. The scene drivers are evaluated continuously, which would be nice to fix but complicated, now it compares the RNA value to see if it actually changed, and avoids the update in that case, which is a useful optimization by itself. (merged from tomato branch)
2012-09-06 11:35:16 +00:00
if (written && new_ptr.id.data) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ID *id = new_ptr.id.data;
Fix T38306: dupliframes causing viewport render to continually restart. Evaluating the animation is causing the object to get tagged as changed, but in this case it's not a permanent change so no one should be notified. Also found a case where the persistent ID for duplis wasn't unique, fixed that as well.
2014-01-21 21:01:12 +01:00
/* for cases like duplifarmes it's only a temporary so don't
* notify anyone of updates */
if (!(id->flag & LIB_ANIM_NO_RECALC)) {
id->flag |= LIB_ID_RECALC;
DAG_id_type_tag(G.main, GS(id->name));
}
Depsgraph/Python: ensure datablocks with animation data get tagged as being updated on frame change.
2011-11-03 10:03:08 +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
}
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
/* successful */
return 1;
}
else {
/* failed to get path */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* 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 */
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("Animato: Invalid path. ID = '%s', '%s[%d]'\n",
Cleanup: redundant NULL checks
2014-05-07 04:35:55 +10:00
(ptr->id.data) ? (((ID *)ptr->id.data)->name + 2) : "<No ID>",
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
path, array_index);
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
}
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
return 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
}
}
/* Simple replacement based data-setting of the FCurve using RNA */
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
static bool animsys_execute_fcurve(PointerRNA *ptr, AnimMapper *remap, FCurve *fcu)
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
{
char *path = NULL;
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
bool free_path = false;
bool ok = 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
/* get path, remapped as appropriate to work in its new environment */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
free_path = animsys_remap_path(remap, fcu->rna_path, &path);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* write value to setting */
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
if (path)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ok = animsys_write_rna_setting(ptr, path, fcu->array_index, fcu->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
/* free temp path-info */
if (free_path)
MEM_freeN(path);
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
}
/* 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
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void animsys_evaluate_fcurves(PointerRNA *ptr, ListBase *list, AnimMapper *remap, 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;
/* calculate then execute each curve */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (fcu = list->first; fcu; fcu = fcu->next) {
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
/* check if this F-Curve doesn't belong to a muted group */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ((fcu->grp == NULL) || (fcu->grp->flag & AGRP_MUTED) == 0) {
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
/* 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) {
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
calculate_fcurve(fcu, ctime);
animsys_execute_fcurve(ptr, remap, fcu);
}
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;
/* 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;
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! */
if ((driver) && !(driver->flag & DRIVER_FLAG_INVALID) /*&& (driver->flag & DRIVER_FLAG_RECALC)*/) {
/* 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 */
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_fcurve(fcu, ctime);
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ok = animsys_execute_fcurve(ptr, NULL, fcu);
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
/* clear recalc flag */
driver->flag &= ~DRIVER_FLAG_RECALC;
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)
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;
/* just in case */
if (ELEM(NULL, id, act))
return;
else
idcode = GS(id->name);
/* 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)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
* - this has problems if there are 2 users, and the first one encountered is the invalid one
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
* in which case, the user will need to manually fix this (?)
*/
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 */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void animsys_evaluate_action_group(PointerRNA *ptr, bAction *act, bActionGroup *agrp, AnimMapper *remap, 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;
/* 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;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ((remap) && (remap->target != act)) remap = NULL;
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
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);
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;
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) {
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_fcurve(fcu, ctime);
animsys_execute_fcurve(ptr, remap, fcu);
}
}
}
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) */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void animsys_evaluate_action(PointerRNA *ptr, bAction *act, AnimMapper *remap, 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;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ((remap) && (remap->target != act)) remap = 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
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);
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 */
animsys_evaluate_fcurves(ptr, &act->curves, remap, ctime);
}
/* ***************************************** */
/* 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);
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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void nlastrip_evaluate_controls(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
{
/* firstly, analytically generate values for influence and time (if applicable) */
if ((strip->flag & NLASTRIP_FLAG_USR_TIME) == 0)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
strip->strip_time = nlastrip_get_frame(strip, ctime, NLATIME_CONVERT_EVAL);
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->flag & NLASTRIP_FLAG_USR_INFLUENCE) == 0)
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
strip->influence = nlastrip_get_influence(strip, 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;
/* create RNA-pointer needed to set values */
RNA_pointer_create(NULL, &RNA_NlaStrip, strip, &strip_ptr);
/* execute these settings as per normal */
NLA SoC: RNA wrapping for NLA Data Most of the relevant properties have been wrapped. - There are still some properties I'm not sure about whether they should be exposed at all (which have been left out for now). Most of these are really internal flags which are used in a few select places. - To maintain the integrity of the settings, I've included some custom code for a few of the setters (i.e. scale/end-frame) where changing one should result in a change in the other and vica-versa. Also, tweaked the wrapping for a few other types. Another side effect of this commit is that I can now uncommented some code for using F-Curves to control the influence and time of the strips. These F-Curves would need to be specifically attached to the NLA-Strip they affect for now (TODO: I need to review this again...), and as such, cannot be used yet since there's no (end-user-accessible) way to do this :)
2009-06-07 06:49:04 +00:00
animsys_evaluate_fcurves(&strip_ptr, &strip->fcurves, NULL, 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
}
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
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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
NlaEvalStrip *nlastrips_ctime_get_strip(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;
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 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 (IN_RANGE_INCL(ctime, strip->start, strip->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
/* 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;
}
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;
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 {
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 next strip - previous strip has ended, but next hasn't begun,
* so blending mode depends on whether strip is being held or not...
style cleanup: whitespace
2012-05-12 16:11:34 +00: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;
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
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;
}
/* 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;
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
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
}
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
}
}
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
* - must not be muted (i.e. will have contribution
*/
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;
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;
}
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 strip's evaluation controls
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
* - skip if no influence (i.e. same effect as muting the strip)
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
* - negative influence is not supported yet... how would that be defined?
*/
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... */
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
nlastrip_evaluate_controls(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;
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: 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) {
case NLASTRIP_TYPE_CLIP:
/* 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;
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... */
nlastrip_evaluate_controls(estrip->prev, estrip->start);
nlastrip_evaluate_controls(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
}
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");
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
nes->strip = estrip;
nes->strip_mode = side;
nes->track_index = index;
nes->strip_time = estrip->strip_time;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
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);
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 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
/* find an NlaEvalChannel that matches the given criteria
* - ptr and prop are the RNA data to find a match for
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static NlaEvalChannel *nlaevalchan_find_match(ListBase *channels, PointerRNA *ptr, PropertyRNA *prop, int array_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
{
NlaEvalChannel *nec;
/* sanity check */
if (channels == NULL)
return NULL;
/* loop through existing channels, checking for a channel which affects the same property */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (nec = channels->first; nec; nec = nec->next) {
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
/* - comparing the PointerRNA's is done by comparing the pointers
* to the actual struct the property resides in, since that all the
* other data stored in PointerRNA cannot allow us to definitively
* identify the data
*/
if ((nec->ptr.data == ptr->data) && (nec->prop == prop) && (nec->index == array_index))
return nec;
}
/* not found */
return NULL;
}
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
/* initialise default value for NlaEvalChannel, so that it doesn't blend things wrong */
static void nlaevalchan_value_init(NlaEvalChannel *nec)
{
PointerRNA *ptr = &nec->ptr;
PropertyRNA *prop = nec->prop;
int index = nec->index;
/* 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
* in NLA strips a lot, e.g. scale) are set correctly.
*/
switch (RNA_property_type(prop)) {
case PROP_BOOLEAN:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00:00
if (RNA_property_array_check(prop))
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
nec->value = (float)RNA_property_boolean_get_default_index(ptr, prop, index);
else
nec->value = (float)RNA_property_boolean_get_default(ptr, prop);
break;
case PROP_INT:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00:00
if (RNA_property_array_check(prop))
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
nec->value = (float)RNA_property_int_get_default_index(ptr, prop, index);
else
nec->value = (float)RNA_property_int_get_default(ptr, prop);
break;
case PROP_FLOAT:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00:00
if (RNA_property_array_check(prop))
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
nec->value = RNA_property_float_get_default_index(ptr, prop, index);
else
nec->value = RNA_property_float_get_default(ptr, prop);
break;
case PROP_ENUM:
nec->value = (float)RNA_property_enum_get_default(ptr, prop);
break;
default:
break;
}
}
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
/* verify that an appropriate NlaEvalChannel for this F-Curve exists */
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
static NlaEvalChannel *nlaevalchan_verify(PointerRNA *ptr, ListBase *channels, NlaEvalStrip *nes, FCurve *fcu, bool *newChan)
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: 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
NlaEvalChannel *nec;
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
PropertyRNA *prop;
PointerRNA new_ptr;
char *path = NULL;
style cleanup
2012-05-27 19:40:36 +00:00
/* short free_path = 0; */
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
/* sanity checks */
if (channels == NULL)
return NULL;
/* get RNA pointer+property info from F-Curve for more convenient handling */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
/* get path, remapped as appropriate to work in its new environment */
style cleanup
2012-05-27 19:40:36 +00:00
/* free_path = */ /* UNUSED */ animsys_remap_path(strip->remap, fcu->rna_path, &path);
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
/* a valid property must be available, and it must be animatable */
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
if (RNA_path_resolve_property(ptr, path, &new_ptr, &prop) == false) {
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("NLA Strip Eval: Cannot resolve path\n");
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 NULL;
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
}
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
/* only ok if animatable */
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
else if (RNA_property_animateable(&new_ptr, prop) == 0) {
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("NLA Strip Eval: Property not animatable\n");
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 NULL;
}
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
/* try to find a match */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
nec = nlaevalchan_find_match(channels, &new_ptr, prop, fcu->array_index);
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: 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
/* allocate a new struct for this if none found */
if (nec == NULL) {
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
nec = MEM_callocN(sizeof(NlaEvalChannel), "NlaEvalChannel");
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
BLI_addtail(channels, 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
/* store property links for writing to the property later */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
nec->ptr = new_ptr;
nec->prop = prop;
nec->index = fcu->array_index;
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
/* initialise value using default value of property [#35856] */
nlaevalchan_value_init(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
*newChan = 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
}
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
else
*newChan = false;
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: 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
/* we can now return */
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 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
/* accumulate (i.e. blend) the given value on to the channel it affects */
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
static void nlaevalchan_accumulate(NlaEvalChannel *nec, NlaEvalStrip *nes, float value, bool newChan)
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
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
NlaStrip *strip = nes->strip;
short blendmode = strip->blendmode;
float inf = strip->influence;
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
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
/* for replace blend mode, and if this is the first strip,
* just replace the value regardless of the influence */
if (newChan && blendmode == NLASTRIP_MODE_REPLACE) {
nec->value = value;
return;
}
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 this is being performed as part of transition evaluation, incorporate
* an additional weighting factor for the influence
*/
if (nes->strip_mode == NES_TIME_TRANSITION_END)
inf *= nes->strip_time;
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
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 */
replace IS_EQ -> IS_EQF for use with floats.
2013-11-10 12:56:50 +00:00
if (IS_EQF(inf, 0.0f)) return;
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 */
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
nec->value += (value * inf);
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
break;
case NLASTRIP_MODE_SUBTRACT:
/* simply subtract the scaled value from the stack */
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
nec->value -= (value * inf);
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
break;
case NLASTRIP_MODE_MULTIPLY:
/* multiply the scaled value with the stack */
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
/* Formula Used:
* result = fac * (a * b) + (1 - fac) * a
*/
nec->value = inf * (nec->value * value) + (1 - inf) * nec->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
break;
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... */
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
/* do linear interpolation
* - the influence of the accumulated data (elsewhere, that is called dstweight)
* is 1 - influence, since the strip's influence is srcweight
*/
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
nec->value = nec->value * (1.0f - inf) + (value * inf);
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
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
/* accumulate the results of a temporary buffer with the results of the full-buffer */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void nlaevalchan_buffers_accumulate(ListBase *channels, ListBase *tmp_buffer, NlaEvalStrip *nes)
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
{
NlaEvalChannel *nec, *necn, *necd;
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
/* optimize - abort if no channels */
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
if (BLI_listbase_is_empty(tmp_buffer))
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;
/* accumulate results in tmp_channels buffer to the accumulation buffer */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (nec = tmp_buffer->first; nec; nec = necn) {
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
/* get pointer to next channel in case we remove the current channel from the temp-buffer */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
necn = nec->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
/* try to find an existing matching channel for this setting in the accumulation buffer */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
necd = nlaevalchan_find_match(channels, &nec->ptr, nec->prop, nec->index);
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 there was a matching channel already in the buffer, accumulate to it,
* otherwise, add the current channel to the buffer for efficiency
*/
if (necd)
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
nlaevalchan_accumulate(necd, nes, 0, nec->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
else {
BLI_remlink(tmp_buffer, nec);
BLI_addtail(channels, nec);
}
}
/* free temp-channels that haven't been assimilated into the buffer */
BLI_freelistN(tmp_buffer);
}
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;
/* 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 {
/* list1 should be added first, and list2 second, with the endpoints of these being the endpoints for result
style cleanup: whitespace
2012-05-12 16:11:34 +00: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;
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
fcm1 = list1->last;
fcm2 = 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
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;
/* 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;
/* get endpoints */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
fcm1 = list1->last;
fcm2 = 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
/* 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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void nlastrip_evaluate_actionclip(PointerRNA *ptr, ListBase *channels, ListBase *modifiers, NlaEvalStrip *nes)
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;
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;
if (strip->act == NULL) {
printf("NLA-Strip Eval Error: Strip '%s' has no Action\n", strip->name);
return;
}
action_idcode_patch_check(ptr->id.data, strip->act);
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);
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);
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
NlaEvalChannel *nec;
float value = 0.0f;
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
bool newChan;
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;
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 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
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
value = evaluate_fcurve(fcu, evaltime);
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
/* apply strip's F-Curve Modifiers on this value
* 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);
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
*/
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
nec = nlaevalchan_verify(ptr, channels, nes, fcu, &newChan);
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
if (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
nlaevalchan_accumulate(nec, nes, value, newChan);
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
/* 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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void nlastrip_evaluate_transition(PointerRNA *ptr, ListBase *channels, ListBase *modifiers, NlaEvalStrip *nes)
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
{
ListBase tmp_channels = {NULL, 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
ListBase tmp_modifiers = {NULL, NULL};
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;
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);
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
/* get the two strips to operate on
* - 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
*/
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
}
/* prepare template for 'evaluation strip'
* - based on the transition strip's evaluation strip data
* - strip_mode is NES_TIME_TRANSITION_* based on which endpoint
More spell and typo fixes (mostly visualise->visualize, grey->gray, normalise->normalize).
2012-07-03 19:09:07 +00:00
* - strip_time is the 'normalized' (i.e. in-strip) time for evaluation,
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
* which doubles up as an additional weighting factor for the strip influences
* which allows us to appear to be 'interpolating' between the two extremes
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
tmp_nes = *nes;
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 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
nlastrip_evaluate(ptr, &tmp_channels, &tmp_modifiers, &tmp_nes);
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
/* second strip */
tmp_nes.strip_mode = NES_TIME_TRANSITION_END;
tmp_nes.strip = s2;
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
nlastrip_evaluate(ptr, &tmp_channels, &tmp_modifiers, &tmp_nes);
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
Correcting a few typos
2013-11-05 10:57:52 +00:00
/* accumulate temp-buffer and full-buffer, using the 'real' 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
nlaevalchan_buffers_accumulate(channels, &tmp_channels, nes);
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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void nlastrip_evaluate_meta(PointerRNA *ptr, ListBase *channels, ListBase *modifiers, NlaEvalStrip *nes)
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;
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: 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
* it's child strips, which get evaluated as if they were some tracks on a strip
* (but with some extra modifiers to apply).
*
* NOTE: keep this in sync with animsys_evaluate_nla()
*/
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
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);
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: 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;
tmp_nes = nlastrips_ctime_get_strip(NULL, &strip->strips, -1, evaltime);
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
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
/* directly evaluate child strip into accumulation buffer...
* - 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) {
nlastrip_evaluate(ptr, channels, &tmp_modifiers, tmp_nes);
/* free temp eval-strip */
MEM_freeN(tmp_nes);
}
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 */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void nlastrip_evaluate(PointerRNA *ptr, ListBase *channels, ListBase *modifiers, NlaEvalStrip *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
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
NlaStrip *strip = nes->strip;
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
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;
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 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
nlastrip_evaluate_actionclip(ptr, channels, modifiers, nes);
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 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
nlastrip_evaluate_transition(ptr, channels, modifiers, nes);
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 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
nlastrip_evaluate_meta(ptr, channels, modifiers, nes);
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;
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
}
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 */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void nladata_flush_channels(ListBase *channels)
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
NlaEvalChannel *nec;
Animato RNA wrapping: It's about time that the RNA wrapping for various parts of the animation system were cleaned up for my recent changes. I've moved some code around (and/or deleted a file or two) in the process.
2009-02-02 11:51:10 +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;
/* for each channel with accumulated values, write its value on the property it affects */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (nec = channels->first; nec; nec = nec->next) {
PointerRNA *ptr = &nec->ptr;
PropertyRNA *prop = nec->prop;
int array_index = nec->index;
float value = nec->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
/* write values - see animsys_write_rna_setting() to sync the code */
style cleanup: changes to brace placement / newlines - for/while/if/switch
2012-04-28 06:31:57 +00:00
switch (RNA_property_type(prop)) {
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 PROP_BOOLEAN:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00:00
if (RNA_property_array_check(prop))
fcurve/boolean evaluation, values below zero are no longer evaluated to true.
2011-05-26 05:35:30 +00:00
RNA_property_boolean_set_index(ptr, prop, array_index, ANIMSYS_FLOAT_AS_BOOL(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
else
fcurve/boolean evaluation, values below zero are no longer evaluated to true.
2011-05-26 05:35:30 +00:00
RNA_property_boolean_set(ptr, prop, ANIMSYS_FLOAT_AS_BOOL(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
break;
case PROP_INT:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00:00
if (RNA_property_array_check(prop))
Proxy Protection Fixes * Mostly revert #24880: Transform Locks affecting animation system. This was implemented as a feature request from Nathan but was not the intended functionality, and actually gives problems instead. The transform locks should really only affect what the user can do, not if the property can be animated internally. * Revert #25868: fix for lib linked scenes not animating. This was needed due to the above feature, but meant that all lib linked properties were editable in the UI. * Make bone properties of on proxy-protected layers not editable. They will be overriden on reload/redo like lib linked data, so should not be edited.
2010-01-12 17:08:28 +00:00
RNA_property_int_set_index(ptr, prop, array_index, (int)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
else
RNA_property_int_set(ptr, prop, (int)value);
break;
case PROP_FLOAT:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00:00
if (RNA_property_array_check(prop))
Proxy Protection Fixes * Mostly revert #24880: Transform Locks affecting animation system. This was implemented as a feature request from Nathan but was not the intended functionality, and actually gives problems instead. The transform locks should really only affect what the user can do, not if the property can be animated internally. * Revert #25868: fix for lib linked scenes not animating. This was needed due to the above feature, but meant that all lib linked properties were editable in the UI. * Make bone properties of on proxy-protected layers not editable. They will be overriden on reload/redo like lib linked data, so should not be edited.
2010-01-12 17:08:28 +00:00
RNA_property_float_set_index(ptr, prop, array_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
else
RNA_property_float_set(ptr, prop, value);
break;
case PROP_ENUM:
RNA_property_enum_set(ptr, prop, (int)value);
break;
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
default:
style cleanup
2012-07-07 22:51:57 +00:00
/* can't do anything with other types of property.... */
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
break;
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
}
/* ---------------------- */
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 Evaluation function - values are calculated and stored in temporary "NlaEvalChannels"
* ! This is exported so that keyframing code can use this for make use of it for anim layers support
* > echannels: (list<NlaEvalChannels>) evaluation channels with calculated values
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void animsys_evaluate_nla(ListBase *echannels, 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
{
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;
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
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 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
NlaStrip dummy_strip = {NULL}; /* dummy strip for active action */
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;
/* skip if we're only considering a track tagged 'solo' */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
if ((adt->flag & ADT_NLA_SOLO_TRACK) && (nlt->flag & NLATRACK_SOLO) == 0)
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
continue;
/* skip if track is muted */
if (nlt->flag & NLATRACK_MUTED)
continue;
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 this track has strips (but maybe they won't be suitable), set has_strips
* - used for mainly for still allowing normal action evaluation...
*/
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;
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
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 */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
nes = nlastrips_ctime_get_strip(&estrips, &nlt->strips, track_index, ctime);
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
}
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
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
* - only do this if we're not exclusively evaluating the 'solo' NLA-track
Mango Bugfix - Actions being tweaked in NLA Editor were not being played back if the track that they belonged to was currently being played back "solo"
2012-05-05 05:23:28 +00:00
* - 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;
Spline IK Bugfix: Binding code had off-by-1 error, which meant that when "Even Divisions" was disabled the length of the wrong bone would get used. This error was most noticeable when the lengths of the bones were quite different - for example, a chain with 3 bones of increasing length. Thanks to "Julius" on BlenderArtists for catching this. Cheers! --- Also, simplified the binding code loop a bit to prevent this sort of error in future.
2010-11-24 23:36:36 +00:00
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
dummy_trackslist.first = dummy_trackslist.last = &dummy_strip;
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
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 ((nlt) && !(adt->flag & ADT_NLA_EDIT_NOMAP)) {
/* edit active action in-place according to its active strip, so copy the data */
memcpy(&dummy_strip, adt->actstrip, sizeof(NlaStrip));
dummy_strip.next = dummy_strip.prev = NULL;
}
else {
/* set settings of dummy NLA strip from AnimData settings */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
dummy_strip.act = adt->action;
dummy_strip.remap = adt->remap;
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) */
calc_action_range(dummy_strip.act, &dummy_strip.actstart, &dummy_strip.actend, 1);
dummy_strip.start = dummy_strip.actstart;
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
dummy_strip.end = (IS_EQF(dummy_strip.actstart, dummy_strip.actend)) ? (dummy_strip.actstart + 1.0f) : (dummy_strip.actend);
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
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
dummy_strip.blendmode = adt->act_blendmode;
dummy_strip.extendmode = adt->act_extendmode;
dummy_strip.influence = adt->act_influence;
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 */
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
}
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 */
nlastrips_ctime_get_strip(&estrips, &dummy_trackslist, -1, ctime);
}
else {
/* special case - evaluate as if there isn't any NLA data */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: this is really just a stop-gap measure... */
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
if (G.debug & G_DEBUG) printf("NLA Eval: Stopgap for active action on NLA Stack - no strips case\n");
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
animsys_evaluate_action(ptr, adt->action, adt->remap, ctime);
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 - 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
return;
}
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
}
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))
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;
/* 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)
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
nlastrip_evaluate(ptr, echannels, NULL, nes);
/* 3. free temporary evaluation data that's not used elsewhere */
BLI_freelistN(&estrips);
}
/* NLA Evaluation function (mostly for use through do_animdata)
* - 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.
*/
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
static void animsys_calculate_nla(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
{
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
ListBase echannels = {NULL, NULL};
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: need to zero out all channels used, otherwise we have problems with threadsafety
* and also when the user jumps between different times instead of moving sequentially... */
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 */
animsys_evaluate_nla(&echannels, ptr, adt, ctime);
/* flush effects of accumulating channels in NLA to the actual data they affect */
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
nladata_flush_channels(&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
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 */
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
BLI_freelistN(&echannels);
}
/* ***************************************** */
/* Overrides System - Public API */
Correcting a few typos
2013-11-05 10:57:52 +00:00
/* Clear all 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
/* Add or get existing Override for given setting */
fix for warnings from Sparse static source code checker, mostly BKE/BLI and python functions. - use NULL rather then 0 where possible (makes code & function calls more readable IMHO). - set static variables and functions (exposed some unused vars/funcs). - use func(void) rather then func() for definitions.
2011-02-13 10:52:18 +00:00
#if 0
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
AnimOverride *BKE_animsys_validate_override(PointerRNA *UNUSED(ptr), char *UNUSED(path), int UNUSED(array_index))
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
/* FIXME: need to define how to get 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
return NULL;
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
}
fix for warnings from Sparse static source code checker, mostly BKE/BLI and python functions. - use NULL rather then 0 where possible (makes code & function calls more readable IMHO). - set static variables and functions (exposed some unused vars/funcs). - use func(void) rather then func() for definitions.
2011-02-13 10:52:18 +00:00
#endif
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 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;
/* for each override, simply execute... */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
for (aor = adt->overrides.first; aor; aor = aor->next)
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_write_rna_setting(ptr, aor->rna_path, aor->array_index, aor->value);
}
/* ***************************************** */
/* Evaluation System - Public API */
/* Overview of how this system works:
* 1) Depsgraph sorts data as necessary, so that data is in an order that means
Spelling Cleanup
2012-03-01 12:20:18 +00:00
* that all dependencies are resolved before dependants.
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) 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
*
* --------------< often in a separate phase... >------------------
*
Spelling Cleanup
2012-03-01 12:20:18 +00:00
* 3) Drivers/expressions are evaluated on top of this, in an order where dependencies are
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
* 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...
*
* --------------< always executed >------------------
*
Spelling Cleanup
2012-03-01 12:20:18 +00:00
* Maintenance of editability of settings (XXX):
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
* 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'.
*
* Unresolved things:
* - Handling of multi-user settings (i.e. time-offset, group-instancing) -> big cache grids or nodal system? but stored where?
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
* - Multiple-block dependencies (i.e. drivers for settings are in both local and higher levels) -> split into separate lists?
*
* Current Status:
* - Currently (as of September 2009), overrides we haven't needed to (fully) implement overrides.
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
* 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
*/
/* Evaluation loop for evaluation animation data
*
* This assumes that the animation-data provided belongs to the ID block in question,
* 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
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_animsys_evaluate_animdata(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;
/* 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;
/* get pointer to ID-block for RNA to use */
RNA_id_pointer_create(id, &id_ptr);
/* recalculate keyframe data:
* - NLA before Active Action, as Active Action behaves as 'tweaking track'
* that overrides 'rough' work in NLA
*/
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 */
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
if ((recalc & ADT_RECALC_ANIM) || (adt->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)) {
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
/* evaluate NLA-stack
* - 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
*/
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
animsys_calculate_nla(&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)
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_action(&id_ptr, adt->action, adt->remap, ctime);
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
/* reset tag */
adt->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
}
/* recalculate drivers
* - 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...
*/
style cleanup: changes to brace placement / newlines - for/while/if/switch
2012-04-28 06:31:57 +00:00
if ((recalc & ADT_RECALC_DRIVERS)
/* XXX for now, don't check yet, as depsgraph hasn't been updated */
/* && (adt->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);
}
/* always execute 'overrides'
* - 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
code cleanup: typos
2013-05-26 12:02:29 +00:00
* - 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);
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
== 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();
}
== 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
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
/* clear recalc flag now */
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
adt->recalc = 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
}
/* 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'
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void BKE_animsys_evaluate_all_animation(Main *main, 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);
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
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
/* macros for less typing
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
* - 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?
*/
#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); \
== 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
BKE_animsys_evaluate_animdata(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
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
/* another macro for the "embedded" nodetree cases
* - 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
style cleanup: whitespace
2012-05-12 16:11:34 +00:00
* for, otherwise they'd get skipped
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
* - ntp = "node tree parent" = datablock where node tree stuff resides
*/
#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); \
== 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
BKE_animsys_evaluate_animdata(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
} \
== 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
BKE_animsys_evaluate_animdata(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
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
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
/* optimization:
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
* 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
* 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");
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
}
/* 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);
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);
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
/* lamps */
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->lamp.first, Lamp, 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
/* 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);
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);
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);
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 - MetaBalls are now animateable
2009-08-03 13:09:23 +00:00
/* metaballs */
EVAL_ANIM_IDS(main->mball.first, ADT_RECALC_ANIM);
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);
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
* 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);
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 */
EVAL_ANIM_IDS(main->latt.first, ADT_RECALC_ANIM);
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);
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 - 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);
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);
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.
*/
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
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);
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);
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
}
/* ***************************************** */
Copy Permalink