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,
|
|
|
|
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*
|
|
|
|
* 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"
|
2009-11-10 20:43:45 +00:00
|
|
|
#include "BLI_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 "BLI_dynstr.h"
|
|
|
|
|
2009-06-23 13:25:31 +00:00
|
|
|
#include "DNA_anim_types.h"
|
2009-09-19 12:36:22 +00:00
|
|
|
#include "DNA_scene_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"
|
|
|
|
#include "RNA_types.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 -------------------------------------------- */
|
|
|
|
|
|
|
|
/* Internal utility to check if ID can have AnimData */
|
|
|
|
static short id_has_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:
|
2009-09-21 06:43:20 +00:00
|
|
|
case ID_MB: case ID_CU: case ID_AR:
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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
|
|
|
|
*/
|
|
|
|
if (id_has_animdata(id)) {
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
if (id_has_animdata(id)) {
|
|
|
|
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
|
|
|
*/
|
2009-01-18 10:41:45 +00:00
|
|
|
if (id_has_animdata(id)) {
|
|
|
|
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 */
|
|
|
|
AnimData *BKE_copy_animdata (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
|
|
|
{
|
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... */
|
|
|
|
dadt->action= copy_action(adt->action);
|
2009-06-06 05:06:46 +00:00
|
|
|
dadt->tmpact= copy_action(adt->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
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
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
|
|
|
*/
|
|
|
|
static char *rna_path_rename_fix (ID *owner_id, char *prefix, char *oldName, char *newName, char *oldpath)
|
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 */
|
|
|
|
if (check_rna_path_is_valid(owner_id, oldpath) == 0) {
|
|
|
|
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
|
|
|
|
if (check_rna_path_is_valid(owner_id, newPath)) {
|
|
|
|
/* 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 */
|
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
|
|
|
static void fcurves_path_rename_fix (ID *owner_id, char *prefix, char *oldName, char *newName, ListBase *curves)
|
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 */
|
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
|
|
|
fcu->rna_path= rna_path_rename_fix(owner_id, prefix, oldName, newName, fcu->rna_path);
|
2009-09-22 11:45:30 +00:00
|
|
|
|
|
|
|
/* driver? */
|
|
|
|
if (fcu->driver) {
|
|
|
|
ChannelDriver *driver= fcu->driver;
|
|
|
|
DriverTarget *dtar;
|
|
|
|
|
|
|
|
/* driver targets */
|
|
|
|
for (dtar= driver->targets.first; dtar; dtar=dtar->next) {
|
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
|
|
|
dtar->rna_path= rna_path_rename_fix(dtar->id, prefix, oldName, newName, dtar->rna_path);
|
2009-09-22 11:45:30 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fix all RNA-Paths for Actions linked to NLA 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
|
|
|
static void nlastrips_path_rename_fix (ID *owner_id, char *prefix, char *oldName, char *newName, ListBase *strips)
|
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)
|
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
|
|
|
fcurves_path_rename_fix(owner_id, prefix, oldName, newName, &strip->act->curves);
|
2009-09-22 11:45:30 +00:00
|
|
|
/* ignore own F-Curves, since those are local... */
|
|
|
|
|
|
|
|
/* check sub-strips (if metas) */
|
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
|
|
|
nlastrips_path_rename_fix(owner_id, prefix, oldName, newName, &strip->strips);
|
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><"]>
|
|
|
|
* i.e. pose.pose_channels["Bone"]
|
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
|
|
|
void BKE_animdata_fix_paths_rename (ID *owner_id, AnimData *adt, char *prefix, char *oldName, char *newName)
|
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 */
|
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
|
|
|
if (ELEM4(NULL, owner_id, adt, oldName, newName))
|
2009-09-22 11:45:30 +00:00
|
|
|
return;
|
|
|
|
|
2009-10-20 04:07:57 +00:00
|
|
|
/* pad the names with [" "] so that only exact matches are made */
|
|
|
|
oldN= BLI_sprintfN("[\"%s\"]", oldName);
|
|
|
|
newN= BLI_sprintfN("[\"%s\"]", newName);
|
|
|
|
|
2009-09-22 11:45:30 +00:00
|
|
|
/* Active action and temp action */
|
|
|
|
if (adt->action)
|
2009-10-20 04:07:57 +00:00
|
|
|
fcurves_path_rename_fix(owner_id, prefix, oldN, newN, &adt->action->curves);
|
2009-09-22 11:45:30 +00:00
|
|
|
if (adt->tmpact)
|
2009-10-20 04:07:57 +00:00
|
|
|
fcurves_path_rename_fix(owner_id, prefix, oldN, newN, &adt->tmpact->curves);
|
2009-09-22 11:45:30 +00:00
|
|
|
|
|
|
|
/* Drivers - Drivers are really F-Curves */
|
2009-10-20 04:07:57 +00:00
|
|
|
fcurves_path_rename_fix(owner_id, prefix, oldN, newN, &adt->drivers);
|
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)
|
2009-10-20 04:07:57 +00:00
|
|
|
nlastrips_path_rename_fix(owner_id, prefix, oldN, newN, &nlt->strips);
|
|
|
|
|
|
|
|
/* 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
|
|
|
}
|
|
|
|
|
|
|
|
/* 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><"]>
|
|
|
|
* i.e. pose.pose_channels["Bone"]
|
|
|
|
*/
|
|
|
|
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); \
|
|
|
|
BKE_animdata_fix_paths_rename(id, adt, prefix, oldName, newName);\
|
|
|
|
}
|
|
|
|
|
|
|
|
/* nodes */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->nodetree.first);
|
|
|
|
|
|
|
|
/* textures */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->tex.first);
|
|
|
|
|
|
|
|
/* lamps */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->lamp.first);
|
|
|
|
|
|
|
|
/* materials */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->mat.first);
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
|
|
|
/* meshes */
|
|
|
|
// TODO...
|
|
|
|
|
|
|
|
/* particles */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->particle.first);
|
|
|
|
|
|
|
|
/* objects */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->object.first);
|
|
|
|
|
|
|
|
/* worlds */
|
|
|
|
RENAMEFIX_ANIM_IDS(mainptr->world.first);
|
|
|
|
|
|
|
|
/* scenes */
|
|
|
|
for (id= mainptr->scene.first; id; id= id->next) {
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id);
|
|
|
|
Scene *scene= (Scene *)id;
|
|
|
|
|
|
|
|
/* do compositing nodes first (since these aren't included in main tree) */
|
|
|
|
if (scene->nodetree) {
|
|
|
|
AnimData *adt2= BKE_animdata_from_id((ID *)scene->nodetree);
|
|
|
|
BKE_animdata_fix_paths_rename((ID *)scene->nodetree, adt2, prefix, oldName, newName);
|
|
|
|
}
|
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
|
|
|
/* now fix scene animation data as per normal */
|
|
|
|
BKE_animdata_fix_paths_rename((ID *)id, adt, prefix, oldName, newName);
|
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
|
|
|
}
|
|
|
|
|
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?
|
|
|
|
KS_Path *BKE_keyingset_find_destination (KeyingSet *ks, ID *id, const char group_name[], const char rna_path[], int array_index, int group_mode)
|
|
|
|
{
|
|
|
|
KS_Path *ksp;
|
|
|
|
|
|
|
|
/* sanity checks */
|
|
|
|
if ELEM(NULL, ks, rna_path)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* ID is optional for relative KeyingSets, but is necessary for absolute KeyingSets */
|
|
|
|
if (id == NULL) {
|
|
|
|
if (ks->flag & KEYINGSET_ABSOLUTE)
|
|
|
|
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 */
|
|
|
|
if ((ks->flag & KEYINGSET_ABSOLUTE) && (id != ksp->id))
|
|
|
|
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");
|
|
|
|
|
2009-02-12 23:25:36 +00:00
|
|
|
if (name)
|
|
|
|
BLI_snprintf(ks->name, 64, name);
|
|
|
|
else
|
2009-08-18 04:15:47 +00:00
|
|
|
strcpy(ks->name, "KeyingSet");
|
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) */
|
2009-08-18 04:15:47 +00:00
|
|
|
BLI_uniquename(list, ks, "KeyingSet", '.', offsetof(KeyingSet, name), 64);
|
2009-03-31 22:36:13 +00:00
|
|
|
|
2009-02-11 12:19:42 +00:00
|
|
|
/* return new KeyingSet for further editing */
|
|
|
|
return ks;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Add a destination to a KeyingSet. Nothing is returned for now...
|
|
|
|
* Checks are performed to ensure that destination is appropriate for the KeyingSet in question
|
|
|
|
*/
|
2009-02-13 01:51:33 +00:00
|
|
|
void BKE_keyingset_add_destination (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) {
|
|
|
|
printf("ERROR: no Keying Set and/or RNA Path to add destination with \n");
|
2009-02-11 12:19:42 +00:00
|
|
|
return;
|
2009-08-25 04:05:37 +00:00
|
|
|
}
|
2009-02-11 12:19:42 +00:00
|
|
|
|
2009-02-15 07:00:13 +00:00
|
|
|
/* ID is optional for relative KeyingSets, but is necessary for absolute KeyingSets */
|
|
|
|
if (id == NULL) {
|
2009-08-25 04:05:37 +00:00
|
|
|
if (ks->flag & KEYINGSET_ABSOLUTE) {
|
|
|
|
printf("ERROR: No ID provided for absolute destination. \n");
|
2009-02-11 12:19:42 +00:00
|
|
|
return;
|
2009-08-25 04:05:37 +00:00
|
|
|
}
|
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 */
|
2009-08-25 04:05:37 +00:00
|
|
|
if (BKE_keyingset_find_destination(ks, id, group_name, rna_path, array_index, groupmode)) {
|
|
|
|
if (G.f & G_DEBUG)
|
|
|
|
printf("ERROR: destination already exists in Keying Set \n");
|
2009-02-15 07:00:13 +00:00
|
|
|
return;
|
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 */
|
|
|
|
if (ks->flag & KEYINGSET_ABSOLUTE) {
|
|
|
|
ksp->id= id;
|
2009-02-12 23:25:36 +00:00
|
|
|
if (group_name)
|
|
|
|
BLI_snprintf(ksp->group, 64, group_name);
|
|
|
|
else
|
|
|
|
strcpy(ksp->group, "");
|
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 */
|
|
|
|
// XXX no checks are performed for templates yet
|
|
|
|
// should array index be checked too?
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2009-08-15 16:43:03 +00:00
|
|
|
/* Copy all KeyingSets in the given list */
|
|
|
|
void BKE_keyingsets_copy(ListBase *newlist, ListBase *list)
|
|
|
|
{
|
|
|
|
KeyingSet *ksn;
|
|
|
|
KS_Path *kspn;
|
|
|
|
|
|
|
|
BLI_duplicatelist(newlist, list);
|
|
|
|
|
|
|
|
for(ksn=newlist->first; ksn; ksn=ksn->next) {
|
|
|
|
BLI_duplicatelist(&ksn->paths, &ksn->paths);
|
|
|
|
|
|
|
|
for(kspn=ksn->paths.first; kspn; kspn=kspn->next)
|
|
|
|
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;
|
|
|
|
|
|
|
|
/* free RNA-path info */
|
|
|
|
MEM_freeN(ksp->rna_path);
|
|
|
|
|
|
|
|
/* free path itself */
|
2009-02-12 10:41:57 +00:00
|
|
|
BLI_freelinkN(&ks->paths, 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
|
|
|
|
*/
|
2009-09-14 16:52:06 +00:00
|
|
|
static short animsys_remap_path (AnimMapper *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;
|
|
|
|
|
|
|
|
/* 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
|
|
|
{
|
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:
|
Implemented dynamic and multidimensional array support in RNA.
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
2009-08-25 17:06:36 +00:00
|
|
|
if (RNA_property_array_length(&new_ptr, prop))
|
2009-02-02 19:57:57 +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:
|
Implemented dynamic and multidimensional array support in RNA.
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
2009-08-25 17:06:36 +00:00
|
|
|
if (RNA_property_array_length(&new_ptr, prop))
|
2009-02-02 19:57:57 +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:
|
Implemented dynamic and multidimensional array support in RNA.
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
2009-08-25 17:06:36 +00:00
|
|
|
if (RNA_property_array_length(&new_ptr, prop))
|
2009-02-02 19:57:57 +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) {
|
|
|
|
printf("Animato: Invalid path. ID = '%s', '%s [%d]' \n",
|
|
|
|
(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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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:
|
Implemented dynamic and multidimensional array support in RNA.
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
2009-08-25 17:06:36 +00:00
|
|
|
if (RNA_property_array_length(ptr, prop))
|
2009-05-16 01:00:41 +00:00
|
|
|
RNA_property_boolean_set_index(ptr, prop, array_index, (int)value);
|
|
|
|
else
|
|
|
|
RNA_property_boolean_set(ptr, prop, (int)value);
|
|
|
|
break;
|
|
|
|
case PROP_INT:
|
Implemented dynamic and multidimensional array support in RNA.
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
2009-08-25 17:06:36 +00:00
|
|
|
if (RNA_property_array_length(ptr, prop))
|
2009-05-16 01:00:41 +00:00
|
|
|
RNA_property_int_set_index(ptr, prop, array_index, (int)value);
|
|
|
|
else
|
|
|
|
RNA_property_int_set(ptr, prop, (int)value);
|
|
|
|
break;
|
|
|
|
case PROP_FLOAT:
|
Implemented dynamic and multidimensional array support in RNA.
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
2009-08-25 17:06:36 +00:00
|
|
|
if (RNA_property_array_length(ptr, prop))
|
2009-05-16 01:00:41 +00:00
|
|
|
RNA_property_float_set_index(ptr, prop, array_index, value);
|
|
|
|
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)
|
|
|
|
{
|
2009-07-31 07:43:47 +00:00
|
|
|
ListBase dummy_trackslist = {NULL, NULL};
|
|
|
|
NlaStrip dummy_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
|
|
|
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++) {
|
|
|
|
/* if tweaking is on and this strip is the tweaking track, stop on this one */
|
|
|
|
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 */
|
|
|
|
if (has_strips) {
|
|
|
|
/* make dummy NLA strip, and add that to the stack */
|
|
|
|
memset(&dummy_strip, 0, sizeof(NlaStrip));
|
|
|
|
dummy_trackslist.first= dummy_trackslist.last= &dummy_strip;
|
|
|
|
|
|
|
|
dummy_strip.act= adt->action;
|
|
|
|
dummy_strip.remap= adt->remap;
|
|
|
|
|
2009-08-25 04:05:37 +00:00
|
|
|
/* action range is calculated taking F-Modifiers into account (which making new strips doesn't do due to the troublesome nature of that) */
|
2009-08-04 10:31:25 +00:00
|
|
|
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;
|
|
|
|
|
|
|
|
/* 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 */
|
|
|
|
AnimOverride *BKE_animsys_validate_override (PointerRNA *ptr, char *path, int array_index)
|
|
|
|
{
|
|
|
|
// FIXME: need to define how to get overrides
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* -------------------- */
|
|
|
|
|
|
|
|
/* Evaluate Overrides */
|
|
|
|
static void animsys_evaluate_overrides (PointerRNA *ptr, AnimData *adt, float ctime)
|
|
|
|
{
|
|
|
|
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))
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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.
|
|
|
|
*/
|
|
|
|
animsys_evaluate_overrides(&id_ptr, adt, ctime);
|
|
|
|
|
|
|
|
/* 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
|
|
|
|
|
|
|
/* macro for less typing
|
|
|
|
* - only evaluate animation data for id if it has users (and not just fake ones)
|
|
|
|
* - whether animdata exists is checked for by the evaluation function, though taking
|
|
|
|
* this outside of the function may make things slightly faster?
|
|
|
|
*/
|
|
|
|
#define EVAL_ANIM_IDS(first, aflag) \
|
2009-01-18 10:41:45 +00:00
|
|
|
for (id= first; id; id= id->next) { \
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id); \
|
2009-08-02 11:05:13 +00:00
|
|
|
if ( (id->us > 1) || (id->us && !(id->flag & LIB_FAKEUSER)) ) \
|
|
|
|
BKE_animsys_evaluate_animdata(id, adt, ctime, aflag); \
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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 */
|
2009-02-09 15:50:09 +00:00
|
|
|
EVAL_ANIM_IDS(main->tex.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
|
|
|
|
|
|
|
/* 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 */
|
2009-02-09 15:50:09 +00:00
|
|
|
EVAL_ANIM_IDS(main->mat.first, 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-06-20 11:44:56 +00:00
|
|
|
// TODO: we probably need the same hack as for curves (ctime-hack)
|
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 */
|
2009-06-20 11:44:56 +00:00
|
|
|
/* we need to perform a special hack here to ensure that the ctime
|
|
|
|
* value of the curve gets set in case there's no animation for that
|
|
|
|
* - it needs to be set before animation is evaluated just so that
|
|
|
|
* animation can successfully override...
|
2009-09-11 00:49:54 +00:00
|
|
|
* - it shouldn't get set when calculating drivers...
|
2009-06-20 11:44:56 +00:00
|
|
|
*/
|
|
|
|
for (id= main->curve.first; id; id= id->next) {
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id);
|
|
|
|
Curve *cu= (Curve *)id;
|
|
|
|
|
2009-09-19 12:36:22 +00:00
|
|
|
/* set ctime variable for curve */
|
2009-06-20 11:44:56 +00:00
|
|
|
cu->ctime= ctime;
|
2009-09-19 12:36:22 +00:00
|
|
|
|
|
|
|
/* now execute animation data on top of this as per normal */
|
2009-06-20 11:44:56 +00:00
|
|
|
BKE_animsys_evaluate_animdata(id, adt, ctime, 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);
|
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
/* meshes */
|
|
|
|
// TODO...
|
2.5: Blender "Animato" - New Animation System
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 */
|
2009-09-19 12:36:22 +00:00
|
|
|
for (id= main->scene.first; id; id= id->next) {
|
|
|
|
AnimData *adt= BKE_animdata_from_id(id);
|
|
|
|
Scene *scene= (Scene *)id;
|
|
|
|
|
|
|
|
/* do compositing nodes first (since these aren't included in main tree) */
|
|
|
|
if (scene->nodetree) {
|
|
|
|
AnimData *adt2= BKE_animdata_from_id((ID *)scene->nodetree);
|
|
|
|
BKE_animsys_evaluate_animdata((ID *)scene->nodetree, adt2, ctime, ADT_RECALC_ANIM);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* now execute scene animation data as per normal */
|
|
|
|
BKE_animsys_evaluate_animdata(id, adt, ctime, 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
|
|
|
}
|
|
|
|
|
|
|
|
/* ***************************************** */
|