2009-06-23 13:25:31 +00:00
|
|
|
/**
|
2009-06-25 04:33:21 +00:00
|
|
|
* $Id$
|
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,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
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
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
2009-03-31 22:36:13 +00:00
|
|
|
#include <stddef.h>
|
2009-05-03 11:46:57 +00:00
|
|
|
#include <float.h>
|
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"
|
|
|
|
|
|
|
|
#include "BLI_blenlib.h"
|
2010-11-09 09:53:17 +00:00
|
|
|
#include "BKE_library.h"
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
#include "BLI_dynstr.h"
|
|
|
|
|
2009-06-23 13:25:31 +00:00
|
|
|
#include "DNA_anim_types.h"
|
2010-11-22 23:59:00 +00:00
|
|
|
#include "DNA_material_types.h"
|
2009-09-19 12:36:22 +00:00
|
|
|
#include "DNA_scene_types.h"
|
2010-11-22 23:59:00 +00:00
|
|
|
#include "DNA_texture_types.h"
|
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"
|
2009-01-18 10:41:45 +00:00
|
|
|
#include "BKE_action.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"
|
2009-05-22 01:16:26 +00:00
|
|
|
#include "BKE_nla.h"
|
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"
|
|
|
|
#include "BKE_utildefines.h"
|
|
|
|
|
|
|
|
#include "RNA_access.h"
|
|
|
|
|
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 */
|
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* Getter/Setter -------------------------------------------- */
|
|
|
|
|
2010-01-27 10:43:14 +00:00
|
|
|
/* Check if ID can have AnimData */
|
|
|
|
short 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)
|
2009-01-18 10:41:45 +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
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* Only some ID-blocks have this info 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
|
|
|
// TODO: finish adding this for the other blocktypes
|
|
|
|
switch (GS(id->name)) {
|
2009-01-18 10:41:45 +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:
|
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:
|
2009-06-24 02:11:36 +00:00
|
|
|
case ID_PA:
|
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:
|
|
|
|
case ID_SCE:
|
|
|
|
{
|
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
|
|
|
}
|
2009-01-18 10:41:45 +00:00
|
|
|
|
|
|
|
/* no AnimData */
|
|
|
|
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
|
|
|
}
|
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.
|
|
|
|
*/
|
|
|
|
AnimData *BKE_animdata_from_id (ID *id)
|
|
|
|
{
|
|
|
|
/* 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
|
|
|
|
*/
|
2010-01-27 10:43:14 +00:00
|
|
|
if (id_type_can_have_animdata(id)) {
|
2009-01-18 10:41:45 +00:00
|
|
|
IdAdtTemplate *iat= (IdAdtTemplate *)id;
|
|
|
|
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
|
|
|
}
|
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
AnimData *BKE_id_add_animdata (ID *id)
|
|
|
|
{
|
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
|
|
|
|
*/
|
2010-01-27 10:43:14 +00:00
|
|
|
if (id_type_can_have_animdata(id)) {
|
2009-01-18 10:41:45 +00:00
|
|
|
IdAdtTemplate *iat= (IdAdtTemplate *)id;
|
2009-01-17 05:36:58 +00:00
|
|
|
|
2009-01-22 10:53:22 +00:00
|
|
|
/* check if there's already AnimData, in which case, don't add */
|
2009-07-31 07:43:47 +00:00
|
|
|
if (iat->adt == NULL) {
|
|
|
|
AnimData *adt;
|
|
|
|
|
|
|
|
/* add animdata */
|
|
|
|
adt= iat->adt= MEM_callocN(sizeof(AnimData), "AnimData");
|
|
|
|
|
|
|
|
/* set default settings */
|
|
|
|
adt->act_influence= 1.0f;
|
|
|
|
}
|
2009-01-22 10:53:22 +00:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
return iat->adt;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Freeing -------------------------------------------- */
|
|
|
|
|
|
|
|
/* Free AnimData used by the nominated ID-block, and clear ID-block's AnimData pointer */
|
|
|
|
void BKE_free_animdata (ID *id)
|
|
|
|
{
|
|
|
|
/* Only some ID-blocks have this info for now, so we cast the
|
|
|
|
* types that do to be of type IdAdtTemplate
|
2009-01-17 05:36:58 +00:00
|
|
|
*/
|
2010-01-27 10:43:14 +00:00
|
|
|
if (id_type_can_have_animdata(id)) {
|
2009-01-18 10:41:45 +00:00
|
|
|
IdAdtTemplate *iat= (IdAdtTemplate *)id;
|
|
|
|
AnimData *adt= iat->adt;
|
|
|
|
|
|
|
|
/* 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--;
|
2009-01-18 10:41:45 +00:00
|
|
|
|
2009-05-22 01:16:26 +00:00
|
|
|
/* free nla data */
|
|
|
|
free_nladata(&adt->nla_tracks);
|
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* free drivers - stored as a list of F-Curves */
|
|
|
|
free_fcurves(&adt->drivers);
|
|
|
|
|
|
|
|
/* free overrides */
|
|
|
|
// TODO...
|
2009-01-17 05:36:58 +00:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* free animdata now */
|
|
|
|
MEM_freeN(adt);
|
|
|
|
iat->adt= NULL;
|
2009-01-17 05:36:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* Freeing -------------------------------------------- */
|
2009-01-17 05:36:58 +00:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* Make a copy of the given AnimData - to be used when copying datablocks */
|
2010-11-09 09:53:17 +00:00
|
|
|
AnimData *BKE_copy_animdata (AnimData *adt, const short 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
|
|
|
{
|
2009-01-18 10:41:45 +00:00
|
|
|
AnimData *dadt;
|
|
|
|
|
|
|
|
/* sanity check before duplicating struct */
|
|
|
|
if (adt == NULL)
|
|
|
|
return NULL;
|
|
|
|
dadt= MEM_dupallocN(adt);
|
|
|
|
|
|
|
|
/* make a copy of action - at worst, user has to delete copies... */
|
2010-11-09 09:53:17 +00:00
|
|
|
if(do_action) {
|
|
|
|
dadt->action= copy_action(adt->action);
|
|
|
|
dadt->tmpact= copy_action(adt->tmpact);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
id_us_plus((ID *)dadt->action);
|
|
|
|
id_us_plus((ID *)dadt->tmpact);
|
|
|
|
}
|
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* duplicate NLA data */
|
2009-05-23 09:36:18 +00:00
|
|
|
copy_nladata(&dadt->nla_tracks, &adt->nla_tracks);
|
2009-01-18 10:41:45 +00:00
|
|
|
|
|
|
|
/* duplicate drivers (F-Curves) */
|
|
|
|
copy_fcurves(&dadt->drivers, &adt->drivers);
|
|
|
|
|
|
|
|
/* don't copy overrides */
|
|
|
|
dadt->overrides.first= dadt->overrides.last= NULL;
|
|
|
|
|
|
|
|
/* 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
|
|
|
}
|
|
|
|
|
2010-11-09 09:53:17 +00:00
|
|
|
int BKE_copy_animdata_id(struct ID *id_to, struct ID *id_from, const short do_action)
|
2010-01-10 20:23:59 +00:00
|
|
|
{
|
|
|
|
AnimData *adt;
|
|
|
|
|
|
|
|
if((id_to && id_from) && (GS(id_to->name) != GS(id_from->name)))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
BKE_free_animdata(id_to);
|
|
|
|
|
|
|
|
adt = BKE_animdata_from_id(id_from);
|
|
|
|
if (adt) {
|
|
|
|
IdAdtTemplate *iat = (IdAdtTemplate *)id_to;
|
2010-11-09 09:53:17 +00:00
|
|
|
iat->adt= BKE_copy_animdata(adt, do_action);
|
2010-01-10 20:23:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2010-11-09 09:53:17 +00:00
|
|
|
void BKE_copy_animdata_id_action(struct ID *id)
|
|
|
|
{
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id);
|
|
|
|
if(adt) {
|
|
|
|
if(adt->action) {
|
|
|
|
((ID *)adt->action)->us--;
|
|
|
|
adt->action= copy_action(adt->action);
|
|
|
|
}
|
|
|
|
if(adt->tmpact) {
|
|
|
|
((ID *)adt->tmpact)->us--;
|
|
|
|
adt->tmpact= copy_action(adt->tmpact);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
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;
|
|
|
|
|
2009-09-22 11:45:30 +00:00
|
|
|
for (strip=strips->first; strip; strip=strip->next) {
|
|
|
|
if (strip->act) make_local_action(strip->act);
|
2009-10-03 04:21:38 +00:00
|
|
|
if (strip->remap && strip->remap->target) make_local_action(strip->remap->target);
|
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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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;
|
2009-09-22 11:45:30 +00:00
|
|
|
|
|
|
|
/* Actions - Active and Temp */
|
|
|
|
if (adt->action) make_local_action(adt->action);
|
|
|
|
if (adt->tmpact) make_local_action(adt->tmpact);
|
|
|
|
/* Remaps */
|
|
|
|
if (adt->remap && adt->remap->target) make_local_action(adt->remap->target);
|
|
|
|
|
|
|
|
/* Drivers */
|
|
|
|
// TODO: need to remap the ID-targets too?
|
|
|
|
|
|
|
|
/* NLA Data */
|
|
|
|
for (nlt=adt->nla_tracks.first; nlt; nlt=nlt->next)
|
|
|
|
make_local_strips(&nlt->strips);
|
|
|
|
}
|
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
|
|
|
|
*/
|
|
|
|
static short animpath_matches_basepath (const char path[], const char basepath[])
|
|
|
|
{
|
|
|
|
/* we need start of path to be basepath */
|
|
|
|
return (path && basepath) && (strstr(path, basepath) == path);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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
|
|
|
|
*/
|
|
|
|
void action_move_fcurves_by_basepath (bAction *srcAct, bAction *dstAct, const char basepath[])
|
|
|
|
{
|
|
|
|
FCurve *fcu, *fcn=NULL;
|
|
|
|
|
|
|
|
/* sanity checks */
|
|
|
|
if ELEM3(NULL, srcAct, dstAct, basepath) {
|
|
|
|
if (G.f & G_DEBUG) {
|
|
|
|
printf("ERROR: action_partition_fcurves_by_basepath(%p, %p, %p) has insufficient info to work with\n",
|
|
|
|
srcAct, dstAct, basepath);
|
|
|
|
}
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
if (animpath_matches_basepath(fcu->rna_path, basepath)) {
|
|
|
|
bActionGroup *agrp = NULL;
|
|
|
|
|
|
|
|
/* if grouped... */
|
|
|
|
if (fcu->grp) {
|
|
|
|
/* make sure there will be a matching group on the other side for the migrants */
|
|
|
|
agrp = action_groups_find_named(dstAct, fcu->grp->name);
|
|
|
|
|
|
|
|
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) {
|
|
|
|
bActionGroup *agrp, *grp=NULL;
|
|
|
|
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
if (agrp->channels.first == NULL)
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
void BKE_animdata_separate_by_basepath (ID *srcID, ID *dstID, ListBase *basepaths)
|
|
|
|
{
|
|
|
|
AnimData *srcAdt=NULL, *dstAdt=NULL;
|
|
|
|
LinkData *ld;
|
|
|
|
|
|
|
|
/* sanity checks */
|
|
|
|
if ELEM(NULL, srcID, dstID) {
|
|
|
|
if (G.f & G_DEBUG)
|
|
|
|
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);
|
|
|
|
|
|
|
|
if ELEM(NULL, srcAdt, dstAdt) {
|
|
|
|
if (G.f & G_DEBUG)
|
|
|
|
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) {
|
|
|
|
dstAdt->action = add_empty_action(srcAdt->action->id.name+2);
|
|
|
|
}
|
|
|
|
else if (dstAdt->action == srcAdt->action) {
|
|
|
|
printf("Argh! Source and Destination share animation! ('%s' and '%s' both use '%s') Making new empty action\n",
|
2010-12-30 05:47:34 +00:00
|
|
|
srcID->name, dstID->name, srcAdt->action->id.name);
|
2010-12-29 11:51:53 +00:00
|
|
|
|
|
|
|
// TODO: review this...
|
2010-12-30 05:41:17 +00:00
|
|
|
id_us_min(&dstAdt->action->id);
|
2010-12-29 11:51:53 +00:00
|
|
|
dstAdt->action = add_empty_action(dstAdt->action->id.name+2);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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) {
|
|
|
|
FCurve *fcu, *fcn=NULL;
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
|
|
|
// TODO: add depsgraph flushing calls?
|
|
|
|
|
|
|
|
/* 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
|
|
|
|
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
|
|
|
|
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 */
|
|
|
|
static short check_rna_path_is_valid (ID *owner_id, char *path)
|
|
|
|
{
|
|
|
|
PointerRNA id_ptr, ptr;
|
|
|
|
PropertyRNA *prop=NULL;
|
|
|
|
|
|
|
|
/* make initial RNA pointer to start resolving from */
|
|
|
|
RNA_id_pointer_create(owner_id, &id_ptr);
|
|
|
|
|
|
|
|
/* try to resolve */
|
|
|
|
return RNA_path_resolve(&id_ptr, path, &ptr, &prop);
|
|
|
|
}
|
|
|
|
|
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
|
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
|
|
|
*/
|
2010-12-03 17:05:21 +00:00
|
|
|
static char *rna_path_rename_fix (ID *owner_id, const char *prefix, char *oldName, char *newName, char *oldpath, int verify_paths)
|
2009-09-22 11:45:30 +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
|
|
|
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,
|
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
|
|
|
*/
|
2009-10-20 04:07:57 +00:00
|
|
|
if ( (prefixPtr && oldNamePtr) && (prefixPtr+prefixLen == oldNamePtr) ) {
|
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 */
|
2010-03-16 07:44:57 +00:00
|
|
|
if (!verify_paths || check_rna_path_is_valid(owner_id, oldpath) == 0) {
|
2009-10-22 03:12:44 +00:00
|
|
|
DynStr *ds= BLI_dynstr_new();
|
|
|
|
char *postfixPtr= oldNamePtr+oldNameLen;
|
|
|
|
char *newPath = NULL;
|
|
|
|
char oldChar;
|
|
|
|
|
|
|
|
/* add the part of the string that goes up to the start of the prefix */
|
|
|
|
if (prefixPtr > oldpath) {
|
|
|
|
oldChar= prefixPtr[0];
|
|
|
|
prefixPtr[0]= 0;
|
|
|
|
BLI_dynstr_append(ds, oldpath);
|
|
|
|
prefixPtr[0]= oldChar;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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 */
|
|
|
|
newPath= BLI_dynstr_get_cstring(ds);
|
|
|
|
BLI_dynstr_free(ds);
|
|
|
|
|
|
|
|
/* check if the new path will solve our problems */
|
|
|
|
// TODO: will need to check whether this step really helps in practice
|
2010-03-16 07:44:57 +00:00
|
|
|
if (!verify_paths || check_rna_path_is_valid(owner_id, newPath)) {
|
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;
|
2009-09-22 11:45:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Check RNA-Paths for a list of F-Curves */
|
2010-12-03 17:05:21 +00:00
|
|
|
static void fcurves_path_rename_fix (ID *owner_id, const char *prefix, char *oldName, char *newName, ListBase *curves, int verify_paths)
|
2009-09-22 11:45:30 +00:00
|
|
|
{
|
|
|
|
FCurve *fcu;
|
|
|
|
|
|
|
|
/* we need to check every curve... */
|
|
|
|
for (fcu= curves->first; fcu; fcu= fcu->next) {
|
|
|
|
/* firstly, handle the F-Curve's own path */
|
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
|
|
|
if (fcu->rna_path)
|
2010-03-16 07:44:57 +00:00
|
|
|
fcu->rna_path= rna_path_rename_fix(owner_id, prefix, oldName, newName, fcu->rna_path, verify_paths);
|
2010-05-17 04:22:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check RNA-Paths for a list of Drivers */
|
2010-12-03 17:05:21 +00:00
|
|
|
static void drivers_path_rename_fix (ID *owner_id, const char *prefix, char *oldName, char *newName, char *oldKey, char *newKey, ListBase *curves, int verify_paths)
|
2010-05-17 04:22:41 +00:00
|
|
|
{
|
|
|
|
FCurve *fcu;
|
|
|
|
|
|
|
|
/* we need to check every curve - drivers are F-Curves too! */
|
|
|
|
for (fcu= curves->first; fcu; fcu= fcu->next) {
|
|
|
|
/* firstly, handle the F-Curve's own path */
|
|
|
|
if (fcu->rna_path)
|
|
|
|
fcu->rna_path= rna_path_rename_fix(owner_id, prefix, oldKey, newKey, fcu->rna_path, verify_paths);
|
2009-09-22 11:45:30 +00:00
|
|
|
|
|
|
|
/* driver? */
|
|
|
|
if (fcu->driver) {
|
|
|
|
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;
|
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 */
|
|
|
|
for (dvar= driver->variables.first; dvar; dvar=dvar->next) {
|
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 */
|
|
|
|
if (dtar->rna_path)
|
2010-05-17 04:22:41 +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) */
|
2010-05-17 04:22:41 +00:00
|
|
|
if (strstr(prefix, "bones")) {
|
|
|
|
if ( ((dtar->id) && (GS(dtar->id->name) == ID_OB)) &&
|
|
|
|
(dtar->pchan_name[0]) && (strcmp(oldName, dtar->pchan_name)==0) )
|
|
|
|
{
|
|
|
|
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
|
2009-09-22 11:45:30 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fix all RNA-Paths for Actions linked to NLA Strips */
|
2010-12-03 17:05:21 +00:00
|
|
|
static void nlastrips_path_rename_fix (ID *owner_id, const char *prefix, char *oldName, char *newName, ListBase *strips, int verify_paths)
|
2009-09-22 11:45:30 +00:00
|
|
|
{
|
|
|
|
NlaStrip *strip;
|
|
|
|
|
|
|
|
/* recursively check strips, fixing only actions... */
|
|
|
|
for (strip= strips->first; strip; strip= strip->next) {
|
|
|
|
/* fix strip's action */
|
|
|
|
if (strip->act)
|
2010-03-16 07:44:57 +00:00
|
|
|
fcurves_path_rename_fix(owner_id, prefix, oldName, newName, &strip->act->curves, verify_paths);
|
2009-09-22 11:45:30 +00:00
|
|
|
/* ignore own F-Curves, since those are local... */
|
|
|
|
|
|
|
|
/* check sub-strips (if metas) */
|
2010-03-16 07:44:57 +00:00
|
|
|
nlastrips_path_rename_fix(owner_id, prefix, oldName, newName, &strip->strips, verify_paths);
|
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><"]>
|
2009-11-18 11:40:55 +00:00
|
|
|
* i.e. pose.bones["Bone"]
|
2009-09-22 11:45:30 +00:00
|
|
|
*/
|
2010-12-03 17:05:21 +00:00
|
|
|
void BKE_animdata_fix_paths_rename (ID *owner_id, AnimData *adt, const char *prefix, char *oldName, char *newName, int oldSubscript, int newSubscript, int verify_paths)
|
2009-09-22 11:45:30 +00:00
|
|
|
{
|
|
|
|
NlaTrack *nlt;
|
2009-10-20 04:07:57 +00:00
|
|
|
char *oldN, *newN;
|
2009-09-22 11:45:30 +00:00
|
|
|
|
|
|
|
/* if no AnimData, no need to proceed */
|
2010-03-16 07:44:57 +00:00
|
|
|
if (ELEM(NULL, owner_id, adt))
|
2009-09-22 11:45:30 +00:00
|
|
|
return;
|
|
|
|
|
2010-05-17 04:22:41 +00:00
|
|
|
if ((oldName != NULL) && (newName != NULL)) {
|
2010-03-16 07:44:57 +00:00
|
|
|
/* pad the names with [" "] so that only exact matches are made */
|
|
|
|
oldN= BLI_sprintfN("[\"%s\"]", oldName);
|
|
|
|
newN= BLI_sprintfN("[\"%s\"]", newName);
|
2010-05-17 04:22:41 +00:00
|
|
|
}
|
|
|
|
else {
|
2010-03-16 07:44:57 +00:00
|
|
|
oldN= BLI_sprintfN("[%d]", oldSubscript);
|
|
|
|
newN= BLI_sprintfN("[%d]", newSubscript);
|
|
|
|
}
|
2009-10-20 04:07:57 +00:00
|
|
|
|
2009-09-22 11:45:30 +00:00
|
|
|
/* Active action and temp action */
|
|
|
|
if (adt->action)
|
2010-03-16 07:44:57 +00:00
|
|
|
fcurves_path_rename_fix(owner_id, prefix, oldN, newN, &adt->action->curves, verify_paths);
|
2009-09-22 11:45:30 +00:00
|
|
|
if (adt->tmpact)
|
2010-03-16 07:44:57 +00:00
|
|
|
fcurves_path_rename_fix(owner_id, prefix, oldN, newN, &adt->tmpact->curves, verify_paths);
|
2009-09-22 11:45:30 +00:00
|
|
|
|
|
|
|
/* Drivers - Drivers are really F-Curves */
|
2010-05-17 04:22:41 +00:00
|
|
|
drivers_path_rename_fix(owner_id, prefix, oldName, newName, oldN, newN, &adt->drivers, verify_paths);
|
2009-09-22 11:45:30 +00:00
|
|
|
|
|
|
|
/* NLA Data - Animation Data for Strips */
|
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
|
|
|
for (nlt= adt->nla_tracks.first; nlt; nlt= nlt->next)
|
2010-03-16 07:44:57 +00:00
|
|
|
nlastrips_path_rename_fix(owner_id, prefix, oldN, newN, &nlt->strips, verify_paths);
|
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
|
|
|
}
|
|
|
|
|
2010-01-30 05:08:42 +00:00
|
|
|
/* Whole Database Ops -------------------------------------------- */
|
|
|
|
|
|
|
|
/* apply the given callback function on all data in main database */
|
2010-12-29 05:20:19 +00:00
|
|
|
void BKE_animdata_main_cb (Main *mainptr, ID_AnimData_Edit_Callback func, void *user_data)
|
2010-01-29 21:16:21 +00:00
|
|
|
{
|
|
|
|
ID *id;
|
|
|
|
|
2010-12-29 05:20:19 +00:00
|
|
|
/* standard data version */
|
2010-01-29 21:16:21 +00:00
|
|
|
#define ANIMDATA_IDS_CB(first) \
|
|
|
|
for (id= first; id; id= id->next) { \
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id); \
|
2010-01-30 05:08:42 +00:00
|
|
|
if (adt) func(id, adt, user_data); \
|
2010-01-29 21:16:21 +00:00
|
|
|
}
|
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) \
|
|
|
|
for (id= first; id; id= id->next) { \
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id); \
|
|
|
|
NtId_Type *ntp= (NtId_Type *)id; \
|
|
|
|
if (ntp->nodetree) { \
|
|
|
|
AnimData *adt2= BKE_animdata_from_id((ID *)ntp); \
|
|
|
|
if (adt2) func(id, adt2, user_data); \
|
|
|
|
} \
|
|
|
|
if (adt) func(id, adt, user_data); \
|
2010-01-29 21:16:21 +00:00
|
|
|
}
|
2010-12-29 05:20:19 +00:00
|
|
|
|
|
|
|
/* nodes */
|
|
|
|
ANIMDATA_IDS_CB(mainptr->nodetree.first);
|
|
|
|
|
|
|
|
/* textures */
|
|
|
|
ANIMDATA_NODETREE_IDS_CB(mainptr->tex.first, Tex);
|
|
|
|
|
|
|
|
/* lamps */
|
|
|
|
ANIMDATA_IDS_CB(mainptr->lamp.first);
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
|
|
|
/* objects */
|
|
|
|
ANIMDATA_IDS_CB(mainptr->object.first);
|
|
|
|
|
|
|
|
/* worlds */
|
|
|
|
ANIMDATA_IDS_CB(mainptr->world.first);
|
|
|
|
|
|
|
|
/* scenes */
|
|
|
|
ANIMDATA_NODETREE_IDS_CB(mainptr->scene.first, Scene);
|
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><"]>
|
2009-11-18 11:40:55 +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
|
|
|
*/
|
2010-01-29 21:16:21 +00:00
|
|
|
/* TODO: use BKE_animdata_main_cb for looping over all data */
|
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
|
|
|
void BKE_all_animdata_fix_paths_rename (char *prefix, char *oldName, char *newName)
|
|
|
|
{
|
|
|
|
Main *mainptr= G.main;
|
|
|
|
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) \
|
|
|
|
for (id= first; id; id= id->next) { \
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id); \
|
2010-03-16 07:44:57 +00:00
|
|
|
BKE_animdata_fix_paths_rename(id, adt, prefix, oldName, newName, 0, 0, 1);\
|
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
|
|
|
}
|
|
|
|
|
2010-12-29 05:20:19 +00:00
|
|
|
/* another version of this macro for nodetrees */
|
|
|
|
#define RENAMEFIX_ANIM_NODETREE_IDS(first, NtId_Type) \
|
|
|
|
for (id= first; id; id= id->next) { \
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id); \
|
|
|
|
NtId_Type *ntp= (NtId_Type *)id; \
|
|
|
|
if (ntp->nodetree) { \
|
|
|
|
AnimData *adt2= BKE_animdata_from_id((ID *)ntp); \
|
|
|
|
BKE_animdata_fix_paths_rename((ID *)ntp, adt2, prefix, oldName, newName, 0, 0, 1);\
|
|
|
|
} \
|
|
|
|
BKE_animdata_fix_paths_rename(id, adt, prefix, oldName, newName, 0, 0, 1);\
|
|
|
|
}
|
|
|
|
|
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 */
|
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 */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->lamp.first);
|
|
|
|
|
|
|
|
/* materials */
|
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);
|
|
|
|
|
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 */
|
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);
|
|
|
|
|
|
|
|
/* objects */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->object.first);
|
|
|
|
|
|
|
|
/* worlds */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->world.first);
|
|
|
|
|
|
|
|
/* scenes */
|
2010-12-29 05:20:19 +00:00
|
|
|
RENAMEFIX_ANIM_NODETREE_IDS(mainptr->scene.first, Scene);
|
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
|
|
|
}
|
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* *********************************** */
|
|
|
|
/* KeyingSet API */
|
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* Finding Tools --------------------------- */
|
|
|
|
|
|
|
|
/* Find the first path that matches the given criteria */
|
|
|
|
// TODO: do we want some method to perform partial matches too?
|
2010-10-16 08:03:28 +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))
|
2009-02-15 07:00:13 +00:00
|
|
|
{
|
|
|
|
KS_Path *ksp;
|
|
|
|
|
|
|
|
/* sanity checks */
|
2010-03-17 11:34:27 +00:00
|
|
|
if ELEM3(NULL, ks, rna_path, id)
|
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)
|
|
|
|
*/
|
|
|
|
for (ksp= ks->paths.first; ksp; ksp= ksp->next) {
|
|
|
|
short eq_id=1, eq_path=1, eq_index=1, eq_group=1;
|
|
|
|
|
|
|
|
/* id */
|
2010-03-17 11:34:27 +00:00
|
|
|
if (id != ksp->id)
|
2009-02-15 07:00:13 +00:00
|
|
|
eq_id= 0;
|
|
|
|
|
|
|
|
/* path */
|
|
|
|
if ((ksp->rna_path==0) || strcmp(rna_path, ksp->rna_path))
|
|
|
|
eq_path= 0;
|
|
|
|
|
2009-09-04 07:26:32 +00:00
|
|
|
/* index - need to compare whole-array setting too... */
|
2009-02-15 07:00:13 +00:00
|
|
|
if (ksp->array_index != array_index)
|
|
|
|
eq_index= 0;
|
|
|
|
|
|
|
|
/* group */
|
|
|
|
if (group_name) {
|
|
|
|
// FIXME: these checks need to be coded... for now, it's not too important though
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if all aspects are ok, return */
|
|
|
|
if (eq_id && eq_path && eq_index && eq_group)
|
|
|
|
return ksp;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* none found */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
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 */
|
|
|
|
KeyingSet *BKE_keyingset_add (ListBase *list, const char name[], short flag, short keyingflag)
|
|
|
|
{
|
|
|
|
KeyingSet *ks;
|
|
|
|
|
|
|
|
/* allocate new KeyingSet */
|
|
|
|
ks= MEM_callocN(sizeof(KeyingSet), "KeyingSet");
|
2010-11-05 07:35:21 +00:00
|
|
|
|
|
|
|
BLI_strncpy(ks->name, name ? name : "KeyingSet", sizeof(ks->name));
|
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
ks->flag= flag;
|
|
|
|
ks->keyingflag= keyingflag;
|
|
|
|
|
|
|
|
/* add KeyingSet to list */
|
|
|
|
BLI_addtail(list, ks);
|
|
|
|
|
2009-03-31 22:36:13 +00:00
|
|
|
/* make sure KeyingSet has a unique name (this helps with identification) */
|
2010-02-18 10:14:49 +00:00
|
|
|
BLI_uniquename(list, ks, "KeyingSet", '.', offsetof(KeyingSet, name), sizeof(ks->name));
|
2009-03-31 22:36:13 +00:00
|
|
|
|
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...
|
2009-02-11 12:19:42 +00:00
|
|
|
* Checks are performed to ensure that destination is appropriate for the KeyingSet in question
|
|
|
|
*/
|
== 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
|
|
|
KS_Path *BKE_keyingset_add_path (KeyingSet *ks, ID *id, const char group_name[], const char rna_path[], int array_index, short flag, short groupmode)
|
2009-02-11 12:19:42 +00:00
|
|
|
{
|
|
|
|
KS_Path *ksp;
|
|
|
|
|
|
|
|
/* sanity checks */
|
2009-08-25 04:05:37 +00:00
|
|
|
if ELEM(NULL, ks, 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
|
|
|
printf("ERROR: no Keying Set and/or RNA Path to add path with \n");
|
|
|
|
return NULL;
|
2009-08-25 04:05:37 +00:00
|
|
|
}
|
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 */
|
2009-02-15 07:00:13 +00:00
|
|
|
if (id == NULL) {
|
== 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
|
|
|
printf("ERROR: No ID provided for Keying Set Path. \n");
|
|
|
|
return NULL;
|
2009-02-11 12:19:42 +00:00
|
|
|
}
|
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* don't add if there is already a matching KS_Path in the KeyingSet */
|
2010-02-27 02:03:33 +00:00
|
|
|
if (BKE_keyingset_find_path(ks, id, group_name, rna_path, array_index, groupmode)) {
|
2009-08-25 04:05:37 +00:00
|
|
|
if (G.f & 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;
|
2009-08-25 04:05:37 +00:00
|
|
|
}
|
2009-02-15 07:00:13 +00:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* allocate a new KeyingSet Path */
|
|
|
|
ksp= MEM_callocN(sizeof(KS_Path), "KeyingSet Path");
|
|
|
|
|
|
|
|
/* just store absolute info */
|
== 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
|
|
|
ksp->id= id;
|
|
|
|
if (group_name)
|
|
|
|
BLI_snprintf(ksp->group, 64, group_name);
|
|
|
|
else
|
2010-11-05 07:35:21 +00:00
|
|
|
ksp->group[0]= '\0';
|
2009-02-11 12:19:42 +00:00
|
|
|
|
2009-04-13 11:15:43 +00:00
|
|
|
/* store additional info for relative paths (just in case user makes the set relative) */
|
|
|
|
if (id)
|
|
|
|
ksp->idtype= GS(id->name);
|
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* just copy path info */
|
== 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
|
|
|
// TODO: should array index be checked too?
|
2009-02-11 12:19:42 +00:00
|
|
|
ksp->rna_path= BLI_strdupn(rna_path, strlen(rna_path));
|
|
|
|
ksp->array_index= array_index;
|
|
|
|
|
|
|
|
/* store flags */
|
|
|
|
ksp->flag= flag;
|
2009-02-13 01:51:33 +00:00
|
|
|
ksp->groupmode= groupmode;
|
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;
|
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 */
|
|
|
|
void BKE_keyingset_free_path (KeyingSet *ks, KS_Path *ksp)
|
|
|
|
{
|
|
|
|
/* sanity check */
|
|
|
|
if ELEM(NULL, ks, ksp)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* free RNA-path info */
|
|
|
|
MEM_freeN(ksp->rna_path);
|
|
|
|
|
|
|
|
/* free path itself */
|
|
|
|
BLI_freelinkN(&ks->paths, ksp);
|
|
|
|
}
|
|
|
|
|
2009-08-15 16:43:03 +00:00
|
|
|
/* Copy all KeyingSets in the given list */
|
== 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
|
|
|
void BKE_keyingsets_copy (ListBase *newlist, ListBase *list)
|
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
|
|
|
|
2009-08-15 16:43:03 +00:00
|
|
|
BLI_duplicatelist(newlist, list);
|
|
|
|
|
== 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
|
|
|
for (ksn=newlist->first; ksn; ksn=ksn->next) {
|
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
|
|
|
|
|
|
|
for (kspn=ksn->paths.first; kspn; kspn=kspn->next)
|
2009-08-15 16:43:03 +00:00
|
|
|
kspn->rna_path= MEM_dupallocN(kspn->rna_path);
|
|
|
|
}
|
|
|
|
}
|
2009-02-11 12:19:42 +00:00
|
|
|
|
|
|
|
/* Freeing Tools --------------------------- */
|
|
|
|
|
|
|
|
/* Free data for KeyingSet but not set itself */
|
|
|
|
void BKE_keyingset_free (KeyingSet *ks)
|
|
|
|
{
|
|
|
|
KS_Path *ksp, *kspn;
|
|
|
|
|
|
|
|
/* sanity check */
|
|
|
|
if (ks == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* free each path as we go to avoid looping twice */
|
|
|
|
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);
|
2009-02-11 12:19:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Free all the KeyingSets in the given list */
|
|
|
|
void BKE_keyingsets_free (ListBase *list)
|
|
|
|
{
|
|
|
|
KeyingSet *ks, *ksn;
|
|
|
|
|
|
|
|
/* sanity check */
|
|
|
|
if (list == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* loop over KeyingSets freeing them
|
|
|
|
* - BKE_keyingset_free() doesn't free the set itself, but it frees its sub-data
|
|
|
|
*/
|
|
|
|
for (ks= list->first; ks; ks= ksn) {
|
|
|
|
ksn= ks->next;
|
|
|
|
BKE_keyingset_free(ks);
|
|
|
|
BLI_freelinkN(list, ks);
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
|
*/
|
2010-10-16 08:03:28 +00:00
|
|
|
static short 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? */
|
2009-07-09 01:04:42 +00:00
|
|
|
//if (remap) {
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
/* find a matching entry... to use to remap */
|
|
|
|
// ...TODO...
|
2009-07-09 01:04:42 +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
|
|
|
|
|
|
|
/* nothing suitable found, so just set dst to look at path (i.e. no alloc/free needed) */
|
|
|
|
*dst= path;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-01-27 05:04:23 +00:00
|
|
|
/* Write the given value to a setting using RNA, and return success */
|
|
|
|
static short 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 */
|
|
|
|
if (RNA_path_resolve(ptr, path, &new_ptr, &prop))
|
|
|
|
{
|
|
|
|
/* set value - only for animatable numerical values */
|
2009-01-18 10:41:45 +00:00
|
|
|
if (RNA_property_animateable(&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
|
|
|
{
|
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
|
|
|
int array_len= RNA_property_array_length(&new_ptr, prop);
|
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
|
|
|
if(array_len && array_index >= array_len)
|
|
|
|
{
|
|
|
|
if (G.f & G_DEBUG) {
|
|
|
|
printf("Animato: Invalid array index. ID = '%s', '%s[%d]', array length is %d \n",
|
|
|
|
(ptr && ptr->id.data) ? (((ID *)ptr->id.data)->name+2) : "<No ID>",
|
|
|
|
path, array_index, array_len-1);
|
|
|
|
}
|
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
|
|
|
|
2009-04-19 13:37:59 +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:
|
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
|
|
|
if (array_len)
|
2010-01-12 17:08:28 +00:00
|
|
|
RNA_property_boolean_set_index(&new_ptr, prop, array_index, (int)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
|
|
|
else
|
|
|
|
RNA_property_boolean_set(&new_ptr, prop, (int)value);
|
|
|
|
break;
|
|
|
|
case PROP_INT:
|
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
|
|
|
if (array_len)
|
2010-01-12 17:08:28 +00:00
|
|
|
RNA_property_int_set_index(&new_ptr, prop, array_index, (int)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
|
|
|
else
|
|
|
|
RNA_property_int_set(&new_ptr, prop, (int)value);
|
|
|
|
break;
|
|
|
|
case PROP_FLOAT:
|
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
|
|
|
if (array_len)
|
2010-01-12 17:08:28 +00:00
|
|
|
RNA_property_float_set_index(&new_ptr, prop, 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
|
|
|
else
|
|
|
|
RNA_property_float_set(&new_ptr, prop, value);
|
|
|
|
break;
|
|
|
|
case PROP_ENUM:
|
|
|
|
RNA_property_enum_set(&new_ptr, prop, (int)value);
|
|
|
|
break;
|
|
|
|
default:
|
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
|
|
|
}
|
|
|
|
}
|
2009-01-27 05:04:23 +00:00
|
|
|
|
|
|
|
/* successful */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* failed to get path */
|
2009-01-29 11:22:34 +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
|
2009-01-29 23:27:24 +00:00
|
|
|
if (G.f & G_DEBUG) {
|
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
|
|
|
printf("Animato: Invalid path. ID = '%s', '%s[%d]' \n",
|
2009-01-29 23:27:24 +00:00
|
|
|
(ptr && ptr->id.data) ? (((ID *)ptr->id.data)->name+2) : "<No ID>",
|
|
|
|
path, array_index);
|
|
|
|
}
|
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 */
|
2009-04-11 06:48:39 +00:00
|
|
|
static short 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;
|
|
|
|
short free_path=0;
|
2009-04-11 06:48:39 +00:00
|
|
|
short ok= 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
|
|
|
|
|
|
|
/* get path, remapped as appropriate to work in its new environment */
|
|
|
|
free_path= animsys_remap_path(remap, fcu->rna_path, &path);
|
|
|
|
|
|
|
|
/* write value to setting */
|
2009-01-22 10:53:22 +00:00
|
|
|
if (path)
|
2009-04-11 06:48:39 +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);
|
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
|
|
|
|
*/
|
|
|
|
static void animsys_evaluate_fcurves (PointerRNA *ptr, ListBase *list, AnimMapper *remap, float ctime)
|
|
|
|
{
|
|
|
|
FCurve *fcu;
|
|
|
|
|
|
|
|
/* calculate then execute each curve */
|
|
|
|
for (fcu= list->first; fcu; fcu= fcu->next)
|
|
|
|
{
|
2009-07-03 10:28:10 +00:00
|
|
|
/* check if this F-Curve doesn't belong to a muted group */
|
|
|
|
if ((fcu->grp == NULL) || (fcu->grp->flag & AGRP_MUTED)==0) {
|
|
|
|
/* check if this curve should be skipped */
|
|
|
|
if ((fcu->flag & (FCURVE_MUTED|FCURVE_DISABLED)) == 0)
|
|
|
|
{
|
|
|
|
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 */
|
|
|
|
static void animsys_evaluate_drivers (PointerRNA *ptr, AnimData *adt, float ctime)
|
|
|
|
{
|
|
|
|
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...
|
|
|
|
*/
|
|
|
|
for (fcu= adt->drivers.first; fcu; fcu= fcu->next)
|
|
|
|
{
|
|
|
|
ChannelDriver *driver= fcu->driver;
|
2009-04-11 06:48:39 +00:00
|
|
|
short ok= 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 this driver's curve should be skipped */
|
|
|
|
if ((fcu->flag & (FCURVE_MUTED|FCURVE_DISABLED)) == 0)
|
|
|
|
{
|
|
|
|
/* check if driver itself is tagged for recalculation */
|
2009-04-11 06:48:39 +00:00
|
|
|
if ((driver) && !(driver->flag & DRIVER_FLAG_INVALID)/*&& (driver->flag & DRIVER_FLAG_RECALC)*/) { // XXX driver recalc flag is not set yet by depsgraph!
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 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
|
|
|
|
calculate_fcurve(fcu, ctime);
|
2009-04-11 06:48:39 +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;
|
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 */
|
|
|
|
|
2009-04-15 01:10:36 +00:00
|
|
|
/* Evaluate Action Group */
|
|
|
|
void animsys_evaluate_action_group (PointerRNA *ptr, bAction *act, bActionGroup *agrp, AnimMapper *remap, float ctime)
|
|
|
|
{
|
|
|
|
FCurve *fcu;
|
|
|
|
|
|
|
|
/* check if mapper is appropriate for use here (we set to NULL if it's inappropriate) */
|
|
|
|
if ELEM(NULL, act, agrp) return;
|
|
|
|
if ((remap) && (remap->target != act)) remap= NULL;
|
|
|
|
|
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;
|
|
|
|
|
2009-04-15 01:10:36 +00:00
|
|
|
/* calculate then execute each curve */
|
|
|
|
for (fcu= agrp->channels.first; (fcu) && (fcu->grp == agrp); fcu= fcu->next)
|
|
|
|
{
|
|
|
|
/* check if this curve should be skipped */
|
|
|
|
if ((fcu->flag & (FCURVE_MUTED|FCURVE_DISABLED)) == 0)
|
|
|
|
{
|
|
|
|
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) */
|
2009-04-15 01:10:36 +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;
|
|
|
|
if ((remap) && (remap->target != act)) remap= NULL;
|
|
|
|
|
|
|
|
/* calculate then execute each curve */
|
|
|
|
animsys_evaluate_fcurves(ptr, &act->curves, remap, ctime);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ***************************************** */
|
|
|
|
/* NLA System - Evaluation */
|
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* calculate influence of strip based for given frame based on blendin/out values */
|
|
|
|
static float nlastrip_get_influence (NlaStrip *strip, float cframe)
|
|
|
|
{
|
|
|
|
/* sanity checks - normalise the blendin/out values? */
|
|
|
|
strip->blendin= (float)fabs(strip->blendin);
|
|
|
|
strip->blendout= (float)fabs(strip->blendout);
|
|
|
|
|
|
|
|
/* result depends on where frame is in respect to blendin/out values */
|
|
|
|
if (IS_EQ(strip->blendin, 0)==0 && (cframe <= (strip->start + strip->blendin))) {
|
|
|
|
/* there is some blend-in */
|
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
|
|
|
return (float)fabs(cframe - strip->start) / (strip->blendin);
|
2009-05-03 11:46:57 +00:00
|
|
|
}
|
|
|
|
else if (IS_EQ(strip->blendout, 0)==0 && (cframe >= (strip->end - strip->blendout))) {
|
|
|
|
/* there is some blend-out */
|
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
|
|
|
return (float)fabs(strip->end - cframe) / (strip->blendout);
|
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
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* evaluate the evaluation time and influence for the strip, storing the results in the strip */
|
2009-06-23 13:25:31 +00:00
|
|
|
static void nlastrip_evaluate_controls (NlaStrip *strip, float ctime)
|
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)
|
2009-06-28 07:32:00 +00:00
|
|
|
strip->strip_time= nlastrip_get_frame(strip, ctime, NLATIME_CONVERT_EVAL);
|
2009-05-03 11:46:57 +00:00
|
|
|
if ((strip->flag & NLASTRIP_FLAG_USR_INFLUENCE) == 0)
|
2009-05-15 13:23:03 +00:00
|
|
|
strip->influence= nlastrip_get_influence(strip, ctime);
|
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 */
|
2009-06-07 06:49:04 +00:00
|
|
|
animsys_evaluate_fcurves(&strip_ptr, &strip->fcurves, NULL, ctime);
|
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
|
|
|
|
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 user can control the evaluation time (using F-Curves), consider the option which allows this time to be clamped
|
|
|
|
* to lie within extents of the action-clip, so that a steady changing rate of progress through several cycles of the clip
|
|
|
|
* can be achieved easily
|
|
|
|
*/
|
|
|
|
// NOTE: if we add any more of these special cases, we better group them up nicely...
|
|
|
|
if ((strip->flag & NLASTRIP_FLAG_USR_TIME) && (strip->flag & NLASTRIP_FLAG_USR_TIME_CYCLIC))
|
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
|
|
|
strip->strip_time= fmod(strip->strip_time - strip->actstart, strip->actend - strip->actstart);
|
2009-05-03 11:46:57 +00:00
|
|
|
}
|
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* gets the strip active at the current time for a list of strips for evaluation purposes */
|
|
|
|
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
|
|
|
{
|
2009-05-03 11:46:57 +00:00
|
|
|
NlaStrip *strip, *estrip=NULL;
|
2009-07-07 11:37:33 +00:00
|
|
|
NlaEvalStrip *nes;
|
|
|
|
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 */
|
2009-07-06 03:44:44 +00:00
|
|
|
for (strip= strips->first; strip; strip= strip->next) {
|
2009-05-03 11:46:57 +00:00
|
|
|
/* check if current time occurs within this strip */
|
2009-06-05 11:51:27 +00:00
|
|
|
if (IN_RANGE_INCL(ctime, strip->start, strip->end)) {
|
2009-05-03 11:46:57 +00:00
|
|
|
/* this strip is active, so try to use it */
|
|
|
|
estrip= strip;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
side= NES_TIME_WITHIN;
|
|
|
|
break;
|
|
|
|
}
|
2009-05-03 11:46:57 +00:00
|
|
|
|
|
|
|
/* if time occurred before current strip... */
|
|
|
|
if (ctime < strip->start) {
|
2009-07-06 03:44:44 +00:00
|
|
|
if (strip == strips->first) {
|
2009-05-03 11:46:57 +00:00
|
|
|
/* before first strip - only try to use it if it extends backwards in time too */
|
|
|
|
if (strip->extendmode == NLASTRIP_EXTEND_HOLD)
|
|
|
|
estrip= strip;
|
|
|
|
|
|
|
|
/* side is 'before' regardless of whether there's a useful strip */
|
2009-07-07 11:37:33 +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 {
|
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...
|
|
|
|
* - only occurs when no transition strip added, otherwise the transition would have
|
|
|
|
* been picked up above...
|
|
|
|
*/
|
|
|
|
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
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
if (strip->extendmode != NLASTRIP_EXTEND_NOTHING)
|
|
|
|
estrip= strip;
|
2009-07-07 11:37:33 +00:00
|
|
|
side= NES_TIME_AFTER;
|
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 */
|
2009-07-06 03:44:44 +00:00
|
|
|
if (strip == strips->last) {
|
2009-05-03 11:46:57 +00:00
|
|
|
if (strip->extendmode != NLASTRIP_EXTEND_NOTHING)
|
|
|
|
estrip= strip;
|
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
side= NES_TIME_AFTER;
|
2009-05-03 11:46:57 +00:00
|
|
|
break;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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))
|
2009-07-07 11:37:33 +00:00
|
|
|
return NULL;
|
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 */
|
|
|
|
ctime= estrip->start;
|
|
|
|
break;
|
|
|
|
case NES_TIME_AFTER: /* extend last frame only */
|
|
|
|
ctime= estrip->end;
|
|
|
|
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
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* evaluate strip's evaluation controls
|
|
|
|
* - skip if no influence (i.e. same effect as muting the strip)
|
|
|
|
* - negative influence is not supported yet... how would that be defined?
|
|
|
|
*/
|
|
|
|
// TODO: this sounds a bit hacky having a few isolated F-Curves stuck on some data it operates on...
|
|
|
|
nlastrip_evaluate_controls(estrip, ctime);
|
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
|
|
|
|
2009-06-19 04:45:56 +00:00
|
|
|
/* check if strip has valid data to evaluate,
|
|
|
|
* and/or perform any additional type-specific actions
|
|
|
|
*/
|
2009-05-03 11:46:57 +00:00
|
|
|
switch (estrip->type) {
|
|
|
|
case NLASTRIP_TYPE_CLIP:
|
|
|
|
/* clip must have some action to evaluate */
|
|
|
|
if (estrip->act == NULL)
|
2009-07-07 11:37:33 +00:00
|
|
|
return NULL;
|
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))
|
2009-07-07 11:37:33 +00:00
|
|
|
return NULL;
|
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);
|
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
|
|
|
}
|
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
/* add to list of strips we need to evaluate */
|
2009-02-02 11:51:10 +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
|
|
|
|
2009-05-03 11:46:57 +00:00
|
|
|
nes->strip= estrip;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
nes->strip_mode= side;
|
2009-05-03 11:46:57 +00:00
|
|
|
nes->track_index= index;
|
2009-06-19 04:45:56 +00:00
|
|
|
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
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/* ---------------------- */
|
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
static NlaEvalChannel *nlaevalchan_find_match (ListBase *channels, PointerRNA *ptr, PropertyRNA *prop, int array_index)
|
|
|
|
{
|
|
|
|
NlaEvalChannel *nec;
|
|
|
|
|
|
|
|
/* sanity check */
|
|
|
|
if (channels == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* loop through existing channels, checking for a channel which affects the same property */
|
|
|
|
for (nec= channels->first; nec; nec= nec->next) {
|
|
|
|
/* - 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* verify that an appropriate NlaEvalChannel for this F-Curve exists */
|
2009-05-15 13:23:03 +00:00
|
|
|
static NlaEvalChannel *nlaevalchan_verify (PointerRNA *ptr, ListBase *channels, NlaEvalStrip *nes, FCurve *fcu, short *newChan)
|
|
|
|
{
|
2009-05-16 01:00:41 +00:00
|
|
|
NlaEvalChannel *nec;
|
2009-05-15 13:23:03 +00:00
|
|
|
NlaStrip *strip= nes->strip;
|
|
|
|
PropertyRNA *prop;
|
|
|
|
PointerRNA new_ptr;
|
|
|
|
char *path = NULL;
|
|
|
|
short free_path=0;
|
|
|
|
|
|
|
|
/* sanity checks */
|
|
|
|
if (channels == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* get RNA pointer+property info from F-Curve for more convenient handling */
|
|
|
|
/* get path, remapped as appropriate to work in its new environment */
|
|
|
|
free_path= animsys_remap_path(strip->remap, fcu->rna_path, &path);
|
|
|
|
|
2009-05-16 01:00:41 +00:00
|
|
|
/* a valid property must be available, and it must be animateable */
|
|
|
|
if (RNA_path_resolve(ptr, path, &new_ptr, &prop) == 0) {
|
|
|
|
if (G.f & G_DEBUG) printf("NLA Strip Eval: Cannot resolve path \n");
|
2009-05-15 13:23:03 +00:00
|
|
|
return NULL;
|
2009-05-16 01:00:41 +00:00
|
|
|
}
|
2009-05-15 13:23:03 +00:00
|
|
|
/* only ok if animateable */
|
2009-05-16 01:00:41 +00:00
|
|
|
else if (RNA_property_animateable(&new_ptr, prop) == 0) {
|
|
|
|
if (G.f & G_DEBUG) printf("NLA Strip Eval: Property not animateable \n");
|
2009-05-15 13:23:03 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2009-05-16 01:00:41 +00:00
|
|
|
/* try to find a match */
|
|
|
|
nec= nlaevalchan_find_match(channels, &new_ptr, prop, fcu->array_index);
|
2009-05-15 13:23:03 +00:00
|
|
|
|
2009-05-16 01:00:41 +00:00
|
|
|
/* allocate a new struct for this if none found */
|
|
|
|
if (nec == NULL) {
|
|
|
|
nec= MEM_callocN(sizeof(NlaEvalChannel), "NlaEvalChannel");
|
|
|
|
*newChan= 1;
|
|
|
|
BLI_addtail(channels, nec);
|
|
|
|
|
|
|
|
nec->ptr= new_ptr;
|
|
|
|
nec->prop= prop;
|
|
|
|
nec->index= fcu->array_index;
|
|
|
|
}
|
2009-06-19 04:45:56 +00:00
|
|
|
else
|
|
|
|
*newChan= 0;
|
2009-05-15 13:23:03 +00:00
|
|
|
|
2009-05-16 01:00:41 +00:00
|
|
|
/* we can now return */
|
2009-05-15 13:23:03 +00:00
|
|
|
return nec;
|
|
|
|
}
|
|
|
|
|
2009-05-16 01:00:41 +00:00
|
|
|
/* accumulate (i.e. blend) the given value on to the channel it affects */
|
|
|
|
static void nlaevalchan_accumulate (NlaEvalChannel *nec, NlaEvalStrip *nes, short newChan, float value)
|
|
|
|
{
|
|
|
|
NlaStrip *strip= nes->strip;
|
2009-06-19 04:45:56 +00:00
|
|
|
short blendmode= strip->blendmode;
|
2009-05-16 01:00:41 +00:00
|
|
|
float inf= strip->influence;
|
|
|
|
|
|
|
|
/* if channel is new, just store value regardless of blending factors, etc. */
|
|
|
|
if (newChan) {
|
|
|
|
nec->value= value;
|
|
|
|
return;
|
|
|
|
}
|
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;
|
2009-05-16 01:00:41 +00:00
|
|
|
|
|
|
|
/* premultiply the value by the weighting factor */
|
|
|
|
if (IS_EQ(inf, 0)) return;
|
|
|
|
value *= inf;
|
|
|
|
|
|
|
|
/* perform blending */
|
2009-06-19 04:45:56 +00:00
|
|
|
switch (blendmode) {
|
2009-05-16 01:00:41 +00:00
|
|
|
case NLASTRIP_MODE_ADD:
|
|
|
|
/* simply add the scaled value on to the stack */
|
|
|
|
nec->value += value;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NLASTRIP_MODE_SUBTRACT:
|
|
|
|
/* simply subtract the scaled value from the stack */
|
|
|
|
nec->value -= value;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NLASTRIP_MODE_MULTIPLY:
|
|
|
|
/* multiply the scaled value with the stack */
|
|
|
|
nec->value *= value;
|
|
|
|
break;
|
|
|
|
|
2009-07-10 00:32:13 +00:00
|
|
|
case NLASTRIP_MODE_REPLACE:
|
2009-05-16 01:00:41 +00:00
|
|
|
default: // TODO: do we really want to blend by default? it seems more uses might prefer add...
|
|
|
|
/* do linear interpolation
|
|
|
|
* - the influence of the accumulated data (elsewhere, that is called dstweight)
|
|
|
|
* is 1 - influence, since the strip's influence is srcweight
|
|
|
|
*/
|
|
|
|
nec->value= nec->value * (1.0f - inf) + value;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* accumulate the results of a temporary buffer with the results of the full-buffer */
|
|
|
|
static void nlaevalchan_buffers_accumulate (ListBase *channels, ListBase *tmp_buffer, NlaEvalStrip *nes)
|
|
|
|
{
|
|
|
|
NlaEvalChannel *nec, *necn, *necd;
|
|
|
|
|
|
|
|
/* optimise - abort if no channels */
|
|
|
|
if (tmp_buffer->first == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* accumulate results in tmp_channels buffer to the accumulation buffer */
|
|
|
|
for (nec= tmp_buffer->first; nec; nec= necn) {
|
|
|
|
/* get pointer to next channel in case we remove the current channel from the temp-buffer */
|
|
|
|
necn= nec->next;
|
|
|
|
|
|
|
|
/* try to find an existing matching channel for this setting in the accumulation buffer */
|
|
|
|
necd= nlaevalchan_find_match(channels, &nec->ptr, nec->prop, nec->index);
|
|
|
|
|
|
|
|
/* 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)
|
|
|
|
nlaevalchan_accumulate(necd, nes, 0, nec->value);
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
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 */
|
|
|
|
static void nlaeval_fmodifiers_join_stacks (ListBase *result, ListBase *list1, ListBase *list2)
|
|
|
|
{
|
|
|
|
FModifier *fcm1, *fcm2;
|
|
|
|
|
|
|
|
/* if list1 is invalid... */
|
|
|
|
if ELEM(NULL, list1, list1->first) {
|
|
|
|
if (list2 && list2->first) {
|
|
|
|
result->first= list2->first;
|
|
|
|
result->last= list2->last;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* if list 2 is invalid... */
|
|
|
|
else if ELEM(NULL, list2, list2->first) {
|
|
|
|
result->first= list1->first;
|
|
|
|
result->last= list1->last;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* list1 should be added first, and list2 second, with the endpoints of these being the endpoints for result
|
|
|
|
* - the original lists must be left unchanged though, as we need that fact for restoring
|
|
|
|
*/
|
|
|
|
result->first= list1->first;
|
|
|
|
result->last= list2->last;
|
|
|
|
|
|
|
|
fcm1= list1->last;
|
|
|
|
fcm2= list2->first;
|
|
|
|
|
|
|
|
fcm1->next= fcm2;
|
|
|
|
fcm2->prev= fcm1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Split two temporary lists of modifiers */
|
|
|
|
static void nlaeval_fmodifiers_split_stacks (ListBase *list1, ListBase *list2)
|
|
|
|
{
|
|
|
|
FModifier *fcm1, *fcm2;
|
|
|
|
|
|
|
|
/* if list1/2 is invalid... just skip */
|
|
|
|
if ELEM(NULL, list1, list2)
|
|
|
|
return;
|
|
|
|
if ELEM(NULL, list1->first, list2->first)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* get endpoints */
|
|
|
|
fcm1= list1->last;
|
|
|
|
fcm2= list2->first;
|
|
|
|
|
|
|
|
/* clear their links */
|
|
|
|
fcm1->next= NULL;
|
|
|
|
fcm2->prev= NULL;
|
|
|
|
}
|
|
|
|
|
2009-05-15 13:23:03 +00:00
|
|
|
/* ---------------------- */
|
|
|
|
|
|
|
|
/* evaluate action-clip strip */
|
2009-07-07 12:17:06 +00:00
|
|
|
static void nlastrip_evaluate_actionclip (PointerRNA *ptr, ListBase *channels, ListBase *modifiers, NlaEvalStrip *nes)
|
2009-05-15 13:23:03 +00:00
|
|
|
{
|
2009-07-07 12:17:06 +00:00
|
|
|
ListBase tmp_modifiers = {NULL, NULL};
|
2009-05-15 13:23:03 +00:00
|
|
|
NlaStrip *strip= nes->strip;
|
|
|
|
FCurve *fcu;
|
|
|
|
float evaltime;
|
|
|
|
|
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);
|
|
|
|
|
2009-05-15 13:23:03 +00:00
|
|
|
/* evaluate strip's modifiers which modify time to evaluate the base curves at */
|
2009-07-07 12:17:06 +00:00
|
|
|
evaltime= evaluate_time_fmodifiers(&tmp_modifiers, NULL, 0.0f, strip->strip_time);
|
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 */
|
|
|
|
for (fcu= strip->act->curves.first; fcu; fcu= fcu->next) {
|
|
|
|
NlaEvalChannel *nec;
|
|
|
|
float value = 0.0f;
|
|
|
|
short newChan = -1;
|
|
|
|
|
|
|
|
/* check if this curve should be skipped */
|
|
|
|
if (fcu->flag & (FCURVE_MUTED|FCURVE_DISABLED))
|
|
|
|
continue;
|
2009-07-03 10:28:10 +00:00
|
|
|
if ((fcu->grp) && (fcu->grp->flag & AGRP_MUTED))
|
|
|
|
continue;
|
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
|
|
|
|
*/
|
|
|
|
value= evaluate_fcurve(fcu, evaltime);
|
|
|
|
|
|
|
|
/* 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)
|
|
|
|
*/
|
2009-07-07 12:17:06 +00:00
|
|
|
evaluate_value_fmodifiers(&tmp_modifiers, fcu, &value, strip->strip_time);
|
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
|
|
|
|
*/
|
|
|
|
nec= nlaevalchan_verify(ptr, channels, nes, fcu, &newChan);
|
2009-05-16 01:00:41 +00:00
|
|
|
if (nec)
|
|
|
|
nlaevalchan_accumulate(nec, nes, newChan, value);
|
2009-05-15 13:23:03 +00:00
|
|
|
}
|
2009-07-07 12:17:06 +00:00
|
|
|
|
|
|
|
/* unlink this strip's modifiers from the parent's modifiers again */
|
|
|
|
nlaeval_fmodifiers_split_stacks(&strip->modifiers, modifiers);
|
2009-05-15 13:23:03 +00:00
|
|
|
}
|
|
|
|
|
2009-06-19 04:45:56 +00:00
|
|
|
/* evaluate transition strip */
|
2009-07-07 12:17:06 +00:00
|
|
|
static void nlastrip_evaluate_transition (PointerRNA *ptr, ListBase *channels, ListBase *modifiers, NlaEvalStrip *nes)
|
2009-06-19 04:45:56 +00:00
|
|
|
{
|
|
|
|
ListBase tmp_channels = {NULL, NULL};
|
2009-07-07 12:17:06 +00:00
|
|
|
ListBase tmp_modifiers = {NULL, NULL};
|
2009-06-19 04:45:56 +00:00
|
|
|
NlaEvalStrip tmp_nes;
|
|
|
|
NlaStrip *s1, *s2;
|
|
|
|
|
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);
|
|
|
|
|
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) {
|
|
|
|
s1= nes->strip->next;
|
|
|
|
s2= nes->strip->prev;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
s1= nes->strip->prev;
|
|
|
|
s2= nes->strip->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* prepare template for 'evaluation strip'
|
|
|
|
* - based on the transition strip's evaluation strip data
|
|
|
|
* - strip_mode is NES_TIME_TRANSITION_* based on which endpoint
|
|
|
|
* - strip_time is the 'normalised' (i.e. in-strip) time for evaluation,
|
|
|
|
* which doubles up as an additional weighting factor for the strip influences
|
|
|
|
* which allows us to appear to be 'interpolating' between the two extremes
|
|
|
|
*/
|
|
|
|
tmp_nes= *nes;
|
|
|
|
|
|
|
|
/* evaluate these strips into a temp-buffer (tmp_channels) */
|
2009-07-07 12:17:06 +00:00
|
|
|
// FIXME: modifier evalation here needs some work...
|
2009-06-19 04:45:56 +00:00
|
|
|
/* first strip */
|
|
|
|
tmp_nes.strip_mode= NES_TIME_TRANSITION_START;
|
|
|
|
tmp_nes.strip= s1;
|
2009-07-12 04:29:36 +00:00
|
|
|
nlastrip_evaluate(ptr, &tmp_channels, &tmp_modifiers, &tmp_nes);
|
2009-06-19 04:45:56 +00:00
|
|
|
|
|
|
|
/* second strip */
|
|
|
|
tmp_nes.strip_mode= NES_TIME_TRANSITION_END;
|
|
|
|
tmp_nes.strip= s2;
|
2009-07-12 04:29:36 +00:00
|
|
|
nlastrip_evaluate(ptr, &tmp_channels, &tmp_modifiers, &tmp_nes);
|
2009-06-19 04:45:56 +00:00
|
|
|
|
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* assumulate temp-buffer and full-buffer, using the 'real' strip */
|
|
|
|
nlaevalchan_buffers_accumulate(channels, &tmp_channels, nes);
|
2009-07-07 12:17:06 +00:00
|
|
|
|
|
|
|
/* unlink this strip's modifiers from the parent's modifiers again */
|
|
|
|
nlaeval_fmodifiers_split_stacks(&nes->strip->modifiers, modifiers);
|
2009-07-07 11:37:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* evaluate meta-strip */
|
2009-07-07 12:17:06 +00:00
|
|
|
static void nlastrip_evaluate_meta (PointerRNA *ptr, ListBase *channels, ListBase *modifiers, NlaEvalStrip *nes)
|
2009-07-07 11:37:33 +00:00
|
|
|
{
|
|
|
|
ListBase tmp_channels = {NULL, NULL};
|
2009-07-07 12:17:06 +00:00
|
|
|
ListBase tmp_modifiers = {NULL, NULL};
|
2009-07-07 11:37:33 +00:00
|
|
|
NlaStrip *strip= nes->strip;
|
|
|
|
NlaEvalStrip *tmp_nes;
|
|
|
|
float evaltime;
|
2009-06-19 04:45:56 +00:00
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* meta-strip was calculated normally to have some time to be evaluated at
|
|
|
|
* and here we 'look inside' the meta strip, treating it as a decorated window to
|
|
|
|
* 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()
|
|
|
|
*/
|
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);
|
2009-06-19 04:45:56 +00:00
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* find the child-strip to evaluate */
|
|
|
|
evaltime= (nes->strip_time * (strip->end - strip->start)) + strip->start;
|
|
|
|
tmp_nes= nlastrips_ctime_get_strip(NULL, &strip->strips, -1, evaltime);
|
|
|
|
if (tmp_nes == NULL)
|
|
|
|
return;
|
2009-06-19 04:45:56 +00:00
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* evaluate child-strip into tmp_channels buffer before accumulating
|
|
|
|
* in the accumulation buffer
|
|
|
|
*/
|
2009-07-07 12:17:06 +00:00
|
|
|
nlastrip_evaluate(ptr, &tmp_channels, &tmp_modifiers, tmp_nes);
|
2009-06-19 04:45:56 +00:00
|
|
|
|
2009-07-07 11:37:33 +00:00
|
|
|
/* assumulate temp-buffer and full-buffer, using the 'real' strip */
|
|
|
|
nlaevalchan_buffers_accumulate(channels, &tmp_channels, nes);
|
|
|
|
|
|
|
|
/* free temp eval-strip */
|
|
|
|
MEM_freeN(tmp_nes);
|
2009-07-07 12:17:06 +00:00
|
|
|
|
|
|
|
/* unlink this strip's modifiers from the parent's modifiers again */
|
|
|
|
nlaeval_fmodifiers_split_stacks(&strip->modifiers, modifiers);
|
2009-06-19 04:45:56 +00:00
|
|
|
}
|
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 */
|
2009-07-07 12:17:06 +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
|
|
|
{
|
2009-07-12 04:29:36 +00:00
|
|
|
NlaStrip *strip= nes->strip;
|
|
|
|
|
|
|
|
/* 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
|
|
|
|
*/
|
|
|
|
// TODO: be careful with this flag, since some edit tools may be running and have set this while animplayback was running
|
|
|
|
if (strip->flag & NLASTRIP_FLAG_EDIT_TOUCHED)
|
|
|
|
return;
|
|
|
|
strip->flag |= NLASTRIP_FLAG_EDIT_TOUCHED;
|
|
|
|
|
2009-05-15 13:23:03 +00:00
|
|
|
/* actions to take depend on the type of strip */
|
2009-07-12 04:29:36 +00:00
|
|
|
switch (strip->type) {
|
2009-05-15 13:23:03 +00:00
|
|
|
case NLASTRIP_TYPE_CLIP: /* action-clip */
|
2009-07-07 12:17:06 +00:00
|
|
|
nlastrip_evaluate_actionclip(ptr, channels, modifiers, nes);
|
2009-05-15 13:23:03 +00:00
|
|
|
break;
|
|
|
|
case NLASTRIP_TYPE_TRANSITION: /* transition */
|
2009-07-07 12:17:06 +00:00
|
|
|
nlastrip_evaluate_transition(ptr, channels, modifiers, nes);
|
2009-05-15 13:23:03 +00:00
|
|
|
break;
|
2009-07-07 11:37:33 +00:00
|
|
|
case NLASTRIP_TYPE_META: /* meta */
|
2009-07-07 12:17:06 +00:00
|
|
|
nlastrip_evaluate_meta(ptr, channels, modifiers, nes);
|
2009-07-07 11:37:33 +00:00
|
|
|
break;
|
2009-05-15 13:23:03 +00:00
|
|
|
}
|
2009-07-12 04:29:36 +00:00
|
|
|
|
|
|
|
/* clear temp recursion safe-check */
|
|
|
|
strip->flag &= ~NLASTRIP_FLAG_EDIT_TOUCHED;
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* write the accumulated settings to */
|
2009-07-07 11:37:33 +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
|
|
|
{
|
2009-05-16 01:00:41 +00:00
|
|
|
NlaEvalChannel *nec;
|
2009-02-02 11:51:10 +00:00
|
|
|
|
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 */
|
|
|
|
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;
|
|
|
|
|
|
|
|
/* write values - see animsys_write_rna_setting() to sync the code */
|
|
|
|
switch (RNA_property_type(prop))
|
|
|
|
{
|
|
|
|
case PROP_BOOLEAN:
|
2010-01-12 17:08:28 +00:00
|
|
|
if (RNA_property_array_length(ptr, prop))
|
|
|
|
RNA_property_boolean_set_index(ptr, prop, array_index, (int)value);
|
2009-05-16 01:00:41 +00:00
|
|
|
else
|
|
|
|
RNA_property_boolean_set(ptr, prop, (int)value);
|
|
|
|
break;
|
|
|
|
case PROP_INT:
|
2010-01-12 17:08:28 +00:00
|
|
|
if (RNA_property_array_length(ptr, prop))
|
|
|
|
RNA_property_int_set_index(ptr, prop, array_index, (int)value);
|
2009-05-16 01:00:41 +00:00
|
|
|
else
|
|
|
|
RNA_property_int_set(ptr, prop, (int)value);
|
|
|
|
break;
|
|
|
|
case PROP_FLOAT:
|
2010-01-12 17:08:28 +00:00
|
|
|
if (RNA_property_array_length(ptr, prop))
|
|
|
|
RNA_property_float_set_index(ptr, prop, array_index, value);
|
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;
|
2009-05-22 01:16:26 +00:00
|
|
|
default:
|
|
|
|
// can't do anything with other types of property....
|
|
|
|
break;
|
2009-05-16 01:00:41 +00:00
|
|
|
}
|
|
|
|
}
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ---------------------- */
|
|
|
|
|
|
|
|
/* NLA 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.
|
|
|
|
*/
|
|
|
|
static void animsys_evaluate_nla (PointerRNA *ptr, AnimData *adt, float ctime)
|
|
|
|
{
|
|
|
|
NlaTrack *nlt;
|
|
|
|
short track_index=0;
|
2009-08-04 10:31:25 +00:00
|
|
|
short has_strips = 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
|
|
|
|
|
|
|
ListBase estrips= {NULL, NULL};
|
|
|
|
ListBase echannels= {NULL, NULL};
|
|
|
|
NlaEvalStrip *nes;
|
|
|
|
|
2009-07-09 01:04:42 +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...
|
|
|
|
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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) */
|
2009-06-05 11:51:27 +00:00
|
|
|
for (nlt=adt->nla_tracks.first; nlt; nlt=nlt->next, track_index++) {
|
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')... */
|
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' */
|
|
|
|
if ((adt->flag & ADT_NLA_SOLO_TRACK) && (nlt->flag & NLATRACK_SOLO)==0)
|
|
|
|
continue;
|
|
|
|
/* skip if track is muted */
|
|
|
|
if (nlt->flag & NLATRACK_MUTED)
|
|
|
|
continue;
|
|
|
|
|
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)
|
|
|
|
has_strips= 1;
|
|
|
|
|
2009-06-05 11:51:27 +00:00
|
|
|
/* otherwise, get strip to evaluate for this channel */
|
2009-07-07 11:37:33 +00:00
|
|
|
nes= nlastrips_ctime_get_strip(&estrips, &nlt->strips, track_index, ctime);
|
|
|
|
if (nes) nes->track= nlt;
|
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
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
if ((adt->action) && !(adt->flag & ADT_NLA_SOLO_TRACK)) {
|
2009-08-04 10:31:25 +00:00
|
|
|
/* if there are strips, evaluate action as per NLA rules */
|
2010-10-16 04:14:26 +00:00
|
|
|
if ((has_strips) || (adt->actstrip)) {
|
2009-08-04 10:31:25 +00:00
|
|
|
/* make dummy NLA strip, and add that to the stack */
|
2010-11-23 08:44:21 +00:00
|
|
|
NlaStrip dummy_strip= {0};
|
|
|
|
ListBase dummy_trackslist;
|
2010-11-24 23:36:36 +00:00
|
|
|
|
2009-08-04 10:31:25 +00:00
|
|
|
dummy_trackslist.first= dummy_trackslist.last= &dummy_strip;
|
|
|
|
|
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 */
|
|
|
|
dummy_strip.act= adt->action;
|
|
|
|
dummy_strip.remap= adt->remap;
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
dummy_strip.end = (IS_EQ(dummy_strip.actstart, dummy_strip.actend)) ? (dummy_strip.actstart + 1.0f): (dummy_strip.actend);
|
|
|
|
|
|
|
|
dummy_strip.blendmode= adt->act_blendmode;
|
|
|
|
dummy_strip.extendmode= adt->act_extendmode;
|
|
|
|
dummy_strip.influence= adt->act_influence;
|
|
|
|
}
|
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 */
|
|
|
|
// TODO: this is really just a stop-gap measure...
|
|
|
|
animsys_evaluate_action(ptr, adt->action, adt->remap, ctime);
|
|
|
|
return;
|
|
|
|
}
|
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 */
|
|
|
|
if (estrips.first == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
/* 2. for each strip, evaluate then accumulate on top of existing channels, but don't set values yet */
|
|
|
|
for (nes= estrips.first; nes; nes= nes->next)
|
2009-07-07 12:17:06 +00:00
|
|
|
nlastrip_evaluate(ptr, &echannels, NULL, 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
|
|
|
|
|
|
|
/* 3. flush effects of accumulating channels in NLA to the actual data they affect */
|
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
|
|
|
|
|
|
|
/* 4. free temporary evaluation data */
|
|
|
|
BLI_freelistN(&estrips);
|
|
|
|
BLI_freelistN(&echannels);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ***************************************** */
|
|
|
|
/* Overrides System - Public API */
|
|
|
|
|
|
|
|
/* Clear all overides */
|
|
|
|
|
|
|
|
/* Add or get existing Override for given setting */
|
2010-10-16 08:03:28 +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
|
|
|
{
|
|
|
|
// FIXME: need to define how to get overrides
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* -------------------- */
|
|
|
|
|
|
|
|
/* Evaluate Overrides */
|
2010-10-16 08:03:28 +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... */
|
|
|
|
for (aor= adt->overrides.first; aor; aor= aor->next)
|
|
|
|
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
|
|
|
|
* that all dependences are resolved before dependants.
|
|
|
|
* 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... >------------------
|
|
|
|
*
|
|
|
|
* 3) Drivers/expressions are evaluated on top of this, in an order where dependences are
|
|
|
|
* resolved nicely.
|
|
|
|
* Note: it may be necessary to have some tools to handle the cases where some higher-level
|
|
|
|
* drivers are added and cause some problematic dependencies that didn't exist in the local levels...
|
|
|
|
*
|
|
|
|
* --------------< always executed >------------------
|
|
|
|
*
|
|
|
|
* Maintainance of editability of settings (XXX):
|
|
|
|
* 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?
|
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.
|
|
|
|
* However, the code fo 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
|
|
|
|
*/
|
|
|
|
void BKE_animsys_evaluate_animdata (ID *id, AnimData *adt, float ctime, short recalc)
|
|
|
|
{
|
|
|
|
PointerRNA id_ptr;
|
|
|
|
|
|
|
|
/* sanity checks */
|
|
|
|
if ELEM(NULL, id, adt)
|
|
|
|
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
|
|
|
|
*/
|
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
|
|
|
// TODO: need to double check that this all works correctly
|
2009-02-09 15:50:09 +00:00
|
|
|
if ((recalc & ADT_RECALC_ANIM) || (adt->recalc & ADT_RECALC_ANIM))
|
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
|
|
|
{
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 */
|
|
|
|
if ((adt->nla_tracks.first) && !(adt->flag & ADT_NLA_EVAL_OFF))
|
|
|
|
{
|
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
|
2009-06-05 11:51:27 +00:00
|
|
|
*/
|
2009-07-31 07:43:47 +00:00
|
|
|
animsys_evaluate_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
|
|
|
}
|
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);
|
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...
|
|
|
|
*/
|
2009-01-22 10:53:22 +00:00
|
|
|
if ((recalc & ADT_RECALC_DRIVERS) /*&& (adt->recalc & ADT_RECALC_DRIVERS)*/) // XXX for now, don't check yet, as depsgraph hasn't been updated
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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
|
|
|
|
* - It is best that we execute this everytime, so that no errors are likely to occur.
|
|
|
|
*/
|
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
|
|
|
|
|
|
|
/* clear recalc flag now */
|
|
|
|
adt->recalc= 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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'
|
|
|
|
*/
|
|
|
|
void BKE_animsys_evaluate_all_animation (Main *main, float ctime)
|
|
|
|
{
|
|
|
|
ID *id;
|
|
|
|
|
2009-01-29 23:27:24 +00:00
|
|
|
if (G.f & G_DEBUG)
|
|
|
|
printf("Evaluate all animation - %f \n", ctime);
|
2009-08-02 11:05:13 +00:00
|
|
|
|
2010-11-22 23:59:00 +00:00
|
|
|
/* macros for less typing
|
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) \
|
2009-01-18 10:41:45 +00:00
|
|
|
for (id= first; id; id= id->next) { \
|
2010-05-13 09:22:05 +00:00
|
|
|
if (ID_REAL_USERS(id) > 0) { \
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id); \
|
2009-08-02 11:05:13 +00:00
|
|
|
BKE_animsys_evaluate_animdata(id, adt, ctime, aflag); \
|
2010-05-13 09:22:05 +00:00
|
|
|
} \
|
2009-08-02 11:05:13 +00:00
|
|
|
}
|
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
|
|
|
|
* for, otherwise they'd get skipped
|
|
|
|
* - ntp = "node tree parent" = datablock where node tree stuff resides
|
|
|
|
*/
|
|
|
|
#define EVAL_ANIM_NODETREE_IDS(first, NtId_Type, aflag) \
|
|
|
|
for (id= first; id; id= id->next) { \
|
|
|
|
if (ID_REAL_USERS(id) > 0) { \
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id); \
|
|
|
|
NtId_Type *ntp= (NtId_Type *)id; \
|
|
|
|
if (ntp->nodetree) { \
|
|
|
|
AnimData *adt2= BKE_animdata_from_id((ID *)ntp->nodetree); \
|
|
|
|
BKE_animsys_evaluate_animdata((ID *)ntp->nodetree, adt2, ctime, ADT_RECALC_ANIM); \
|
|
|
|
} \
|
|
|
|
BKE_animsys_evaluate_animdata(id, adt, ctime, aflag); \
|
|
|
|
} \
|
|
|
|
}
|
2009-08-02 11:05:13 +00:00
|
|
|
|
|
|
|
/* optimisation:
|
|
|
|
* 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
|
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
|
|
|
|
* set correctly, so this optimisation must be skipped in that case...
|
2009-08-02 11:05:13 +00:00
|
|
|
*/
|
2009-09-11 00:49:54 +00:00
|
|
|
if ((main->action.first == NULL) && (main->curve.first == NULL)) {
|
2009-08-02 11:05:13 +00:00
|
|
|
if (G.f & G_DEBUG)
|
|
|
|
printf("\tNo Actions, so no animation needs to be evaluated...\n");
|
|
|
|
|
|
|
|
return;
|
2009-01-18 10:41:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* nodes */
|
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 */
|
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 */
|
2009-02-09 15:50:09 +00:00
|
|
|
EVAL_ANIM_IDS(main->lamp.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
|
|
|
|
|
|
|
/* materials */
|
2010-11-22 23:59:00 +00:00
|
|
|
EVAL_ANIM_NODETREE_IDS(main->mat.first, Material, ADT_RECALC_ANIM);
|
2009-01-18 10:41:45 +00:00
|
|
|
|
|
|
|
/* cameras */
|
2009-02-09 15:50:09 +00:00
|
|
|
EVAL_ANIM_IDS(main->camera.first, ADT_RECALC_ANIM);
|
2009-01-18 10:41:45 +00:00
|
|
|
|
|
|
|
/* shapekeys */
|
2009-02-09 15:50:09 +00:00
|
|
|
EVAL_ANIM_IDS(main->key.first, ADT_RECALC_ANIM);
|
2009-01-18 10:41:45 +00:00
|
|
|
|
2009-08-03 13:09:23 +00:00
|
|
|
/* metaballs */
|
|
|
|
EVAL_ANIM_IDS(main->mball.first, ADT_RECALC_ANIM);
|
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* curves */
|
2010-10-21 10:28:06 +00:00
|
|
|
EVAL_ANIM_IDS(main->curve.first, ADT_RECALC_ANIM);
|
2009-01-18 10:41:45 +00:00
|
|
|
|
2009-09-21 06:43:20 +00:00
|
|
|
/* armatures */
|
|
|
|
EVAL_ANIM_IDS(main->armature.first, ADT_RECALC_ANIM);
|
|
|
|
|
2010-12-13 06:31:49 +00:00
|
|
|
/* lattices */
|
|
|
|
EVAL_ANIM_IDS(main->latt.first, ADT_RECALC_ANIM);
|
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* meshes */
|
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
|
|
|
|
2009-06-24 02:11:36 +00:00
|
|
|
/* particles */
|
|
|
|
EVAL_ANIM_IDS(main->particle.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 */
|
2009-04-15 01:10:36 +00:00
|
|
|
/* ADT_RECALC_ANIM doesn't need to be supplied here, since object AnimData gets
|
2009-09-30 04:59:14 +00:00
|
|
|
* this tagged by Depsgraph on framechange. This optimisation means that objects
|
|
|
|
* linked from other (not-visible) scenes will not need their data calculated.
|
2009-04-15 01:10:36 +00:00
|
|
|
*/
|
2009-09-30 04:59:14 +00:00
|
|
|
EVAL_ANIM_IDS(main->object.first, 0);
|
2009-01-18 10:41:45 +00:00
|
|
|
|
|
|
|
/* worlds */
|
2009-02-09 15:50:09 +00:00
|
|
|
EVAL_ANIM_IDS(main->world.first, ADT_RECALC_ANIM);
|
2009-01-18 10:41:45 +00:00
|
|
|
|
|
|
|
/* scenes */
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/* ***************************************** */
|