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

124 lines
4.3 KiB
C++
Raw Normal View History

2.5 - Optimisations for Keyframe Drawing in DopeSheet Keyframes are now prepared for drawing by being added to a binary-tree structure instead of using insertion-sort on a Double-Linked List. This gives rather significant improvements on a few bad cases (*). I've implemented a basic Red-Black Tree whose nodes/data-structures can also be used as a simple Double-Linked List (ListBase) for this purpose. The implementation of this tree currently does not have support for removing individual nodes, since such capabilities aren't needed yet. Stats (using keyframes from an imported .bvh animation file): * When only the keyframes are drawn (i.e. long keyframes are not identified), the time needed to draw the DopeSheet region 10 times went down from 4000ms to about 300ms. * When long keyframes are considered as well, the same test has gone from 6000ms to 3000ms. There is still a bottleneck there that I haven't been able to remove yet (an attempt at this made the runtimes go through the roof - 32000 ms for the test done here). Assorted Notes: * Added missing headers for some files * Fixed profiling flags for mingw. There was an extra space which prevented the sound-code from compiling.
2009-07-18 07:11:37 +00:00
/**
* $Id$
*
* ***** 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.
*
* Contributor(s): Joshua Leung (original author)
*
* ***** 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
*/
#ifndef BKE_ANIM_SYS_H
#define BKE_ANIM_SYS_H
struct ID;
struct ListBase;
struct Main;
struct AnimData;
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
struct KeyingSet;
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
struct KS_Path;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
struct PointerRNA;
struct bAction;
Fixing linux compiling
2009-04-15 10:18:58 +00:00
struct bActionGroup;
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
struct AnimMapper;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 */
/* Get AnimData from the given ID-block. */
struct AnimData *BKE_animdata_from_id(struct ID *id);
2.5 - AnimData fixes * Made AnimData blocks be stored as pointer instead of directly in the ID-datablock, so that fewer files will need to be recompiled everytime some animation settings change. * Tried to fix some of the compiler errors that pop up in Yafray code. If this commit doesn't fix it, just disable Yafray code for now (WITH_BF_YAFRAY=0 for scons)...
2009-01-17 05:36:58 +00:00
/* Add AnimData to the given ID-block */
struct AnimData *BKE_id_add_animdata(struct ID *id);
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* Free AnimData */
void BKE_free_animdata(struct ID *id);
/* Copy AnimData */
struct AnimData *BKE_copy_animdata(struct AnimData *adt);
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 */
void BKE_animdata_make_local(struct AnimData *adt);
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* ************************************* */
/* KeyingSets API */
/* Used to create a new 'custom' KeyingSet for the user, that will be automatically added to the stack */
struct KeyingSet *BKE_keyingset_add(struct ListBase *list, const char name[], short flag, short keyingflag);
/* Add a destination to a KeyingSet */
Keying Sets: Wrapped KeyingSets in RNA * The settings of KeyingSets can now be viewed/modified through RNA. * Shuffled RNA wrapping for AnimData over to its own file * Moved insert-key flags to DNA_anim_types.h, as they're now used for KeyingSets.
2009-02-13 01:51:33 +00:00
void BKE_keyingset_add_destination(struct KeyingSet *ks, struct ID *id, const char group_name[], const char rna_path[], int array_index, short flag, short groupmode);
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
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
/* Find the destination matching the criteria given */
Keying Sets: Added 'remove selected from active set' (Alt-K) operator in Outliner * Cleaned up the helper functions for the Outliner operators which deal with Keying Sets * Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later * Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
2009-02-15 07:00:13 +00:00
struct KS_Path *BKE_keyingset_find_destination(struct KeyingSet *ks, struct ID *id, const char group_name[], const char rna_path[], int array_index, int group_mode);
2.5: Screen/Scene New/Delete operators. Implementation Note: * Moved the scene copy/unlink code back into blenkernel, with the exception of the copy single user stuff which is still in object_edit.c. * Uses SCREENDELETE notifier like SCREENBROWSE, seems only clean way to do this now.
2009-08-15 16:43:03 +00:00
/* Copy all KeyingSets in the given list */
void BKE_keyingsets_copy(struct ListBase *newlist, struct ListBase *list);
Keying Sets: Initial commit of skeleton code When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose. Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu). Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
2009-02-11 12:19:42 +00:00
/* Free data for KeyingSet but not set itself */
void BKE_keyingset_free(struct KeyingSet *ks);
/* Free all the KeyingSets in the given list */
void BKE_keyingsets_free(struct ListBase *list);
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
/* ************************************* */
/* Path Fixing API */
/* Fix all the paths for the given ID+AnimData */
void BKE_animdata_fix_paths_rename(struct ID *owner_id, struct AnimData *adt, char *prefix, char *oldName, char *newName);
/* Fix all the paths for the entire database... */
void BKE_all_animdata_fix_paths_rename(char *prefix, char *oldName, char *newName);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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: overrides, remapping, and path-finding api's
/* ************************************* */
/* Evaluation API */
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
/* ------------- Main API -------------------- */
/* In general, these ones should be called to do all animation evaluation */
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 evaluating animation data */
void BKE_animsys_evaluate_animdata(struct ID *id, struct AnimData *adt, float ctime, short recalc);
/* Evaluation of all ID-blocks with Animation Data blocks - Animation Data Only */
void BKE_animsys_evaluate_all_animation(struct Main *main, float ctime);
2.5 PoseLib - First steps to get PoseLib to work in 2.5 * Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy. * Added new Animato evaluation functions specifically for use by PoseLib. * Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code! Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
2009-04-15 01:10:36 +00:00
/* ------------ Specialised API --------------- */
/* There are a few special tools which require these following functions. They are NOT to be used
* for standard animation evaluation UNDER ANY CIRCUMSTANCES!
*
* i.e. Pose Library (PoseLib) uses some of these for selectively applying poses, but
* Particles/Sequencer performing funky time manipulation is not ok.
*/
/* Evaluate Action (F-Curve Bag) */
void animsys_evaluate_action(struct PointerRNA *ptr, struct bAction *act, struct AnimMapper *remap, float ctime);
/* Evaluate Action Group */
void animsys_evaluate_action_group(struct PointerRNA *ptr, struct bAction *act, struct bActionGroup *agrp, struct 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
/* ************************************* */
#endif /* BKE_ANIM_SYS_H*/
Copy Permalink