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

2875 lines
81 KiB
C
Raw Normal View History

doxygen: prevent GPL license block from being parsed as doxygen comment.
2011-02-23 10:52:22 +00:00
/*
NLA SoC: Big Commit - Restored NLA-Mapping Corrections In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :) To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with. I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here... Also, added proper license headers to new NLA files. TODO: - testing + bugfixing due to this commit - show range of keyframes in NLA Editor active-action line
2009-06-23 13:25:31 +00:00
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
correct fsf address
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
NLA SoC: Big Commit - Restored NLA-Mapping Corrections In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :) To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with. I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here... Also, added proper license headers to new NLA files. TODO: - testing + bugfixing due to this commit - show range of keyframes in NLA Editor active-action line
2009-06-23 13:25:31 +00:00
*
* The Original Code is Copyright (C) 2009 Blender Foundation, Joshua Leung
* All rights reserved.
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
doxygen: blender/blenkernel tagged.
2011-02-27 20:40:57 +00:00
doxygen: add newline after \file While \file doesn't need an argument, it can't have another doxy command after it.
2019-02-18 08:08:12 +11:00
/** \file
* \ingroup bke
doxygen: blender/blenkernel tagged.
2011-02-27 20:40:57 +00:00
*/
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
#include <math.h>
#include <stdio.h>
2.5: * Added extra parameter to generic unique name finding function BLI_uniquename() for specifying the delimeter between non-unique parts of the name and digits. * Driver target variables now get unique names by default.
2009-04-16 13:10:08 +00:00
#include <stddef.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 <string.h>
F-Curve Modifiers: Generator Modifier Code * Rewrote the Generator modifier to be more efficient and support more options * A few UI tweaks for this, but the UI for this is still not yet functional though.
2009-03-16 01:12:37 +00:00
#include <float.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 "DNA_anim_types.h"
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
#include "DNA_constraint_types.h"
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
#include "DNA_object_types.h"
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
#include "BLI_blenlib.h"
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
#include "BLI_math.h"
Code cleanup: rename BLI_math_easing to BLI_easing Many hard coded values and really specific to time & keyframes.
2014-03-25 08:00:51 +11:00
#include "BLI_easing.h"
Attempt to make drivers more safe for threading There were some reported data race conditions in the python interpreter which seems to be rather valid. Surely this is not very pretty solution, but it might solve some annoying bugs related on threading.
2015-05-18 13:52:01 +05:00
#include "BLI_threads.h"
Cleanup/refactor: Add new BLI_string_util. Things like `BLI_uniquename` had nothing, but really nothing to do in BLI_path_util files! Also, got rid of length limitation in `BLI_uniquename_cb`, we can use alloca here to avoid overhead of malloc while keeping free size (within reasonable limits of course).
2017-01-16 17:33:34 +01:00
#include "BLI_string_utils.h"
split BKE_utildefines.h, now it only has blender specific defines like GS() MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h. no functional changes.
2011-01-07 18:36:47 +00:00
#include "BLI_utildefines.h"
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
#include "BLI_expr_pylike_eval.h"
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
#include "BLI_alloca.h"
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
Refactor translation code out of blenfont - Add blentranslation `BLT_*` module. - moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`). - moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
2015-08-16 17:32:01 +10:00
#include "BLT_translation.h"
More new data names translation (most cases should be covered now). Also done a few cleanup here and there...
2013-03-25 08:29:06 +00:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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"
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
#include "BKE_animsys.h"
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
#include "BKE_action.h"
Bugfix #21384: Bone Driven Shapekeys Child Evaluation Problem Transform channel drivers for bones in 'localspace' was using the wrong matrix when getting the transforms. I had been assuming that pchan->chan_mat always contained only the matrix-ised transform values stored in the pchan (which is true while constraints are being evaluated, but not afterwards). Changes: - Added a new function to calculate this matrix instead of directly writing it on the pchan->chan_matrix field. - Also, made the normalisation of the quaternion values during this process be done on a temp var instead of on the stored value. This was a constant source of confusion in the past, so let's see if we can do without it now :) Unrelated to this commit, I've also fixed a compiler warning with previous commit that I missed (missing include).
2010-03-01 05:19:07 +00:00
#include "BKE_armature.h"
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
#include "BKE_constraint.h"
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
#include "BKE_context.h"
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
#include "BKE_curve.h"
Animato: * Drivers view in Graph Editor now displays drivers only, instead of displaying normal Animation data. * 'Materials' channel is now only shown under an Object when there are Materials with animation data... * Hid more debug prints behind debug flag. These should be removed...
2009-01-30 08:10:31 +00:00
#include "BKE_global.h"
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
#include "BKE_object.h"
Fix T46163: NLA properties with drivers aren't displayed as having drivers While such drivers will generally get evaluated too late to be of much use during animations, it can still be useful to allow using drivers to control a whole bunch of NLA strip properties (i.e. syncing NLA strip timings via a single property/control). Keyframe insertion however is still not allowed on these properties (and an error message will now be displayed when trying to do so, instead of silently failing), as it is useless.
2017-10-20 17:04:57 +13:00
#include "BKE_nla.h"
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
#include "RNA_access.h"
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
#include "atomic_ops.h"
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
#include "CLG_log.h"
rename and negate DISABLE_PYTHON --> WITH_PYTHON
2010-10-31 04:11:39 +00:00
#ifdef WITH_PYTHON
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
#include "BPY_extern.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
#endif
#define SMALL -1.0e-10
#define SELECT 1
Building without Python works again
2015-05-19 11:34:52 +10:00
#ifdef WITH_PYTHON
Attempt to make drivers more safe for threading There were some reported data race conditions in the python interpreter which seems to be rather valid. Surely this is not very pretty solution, but it might solve some annoying bugs related on threading.
2015-05-18 13:52:01 +05:00
static ThreadMutex python_driver_lock = BLI_MUTEX_INITIALIZER;
Building without Python works again
2015-05-19 11:34:52 +10:00
#endif
Attempt to make drivers more safe for threading There were some reported data race conditions in the python interpreter which seems to be rather valid. Surely this is not very pretty solution, but it might solve some annoying bugs related on threading.
2015-05-18 13:52:01 +05:00
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
static CLG_LogRef LOG = {"bke.fcurve"};
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* ************************** Data-Level Functions ************************* */
/* ---------------------- Freeing --------------------------- */
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
/* Frees the F-Curve itself too, so make sure BLI_remlink is called before calling this... */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void free_fcurve(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
{
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
if (fcu == 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
return;
add some missing NULL checks, a few parts of the code used a pointer then checked it for NULL after. also made it more clear that some areas assume the pointer isnt null (remove redundant NULL checks).
2012-09-11 02:18: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
/* free curve data */
Replace freeing checks with MEM_SAFE_FREE
2017-10-17 00:44:20 +13:00
MEM_SAFE_FREE(fcu->bezt);
MEM_SAFE_FREE(fcu->fpt);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* free RNA-path, as this were allocated when getting the path string */
Replace freeing checks with MEM_SAFE_FREE
2017-10-17 00:44:20 +13:00
MEM_SAFE_FREE(fcu->rna_path);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* free extra data - i.e. modifiers, and driver */
fcurve_free_driver(fcu);
NLA SoC: Separating out F-Modifier API * F-Modifier API is now in its own file in blenkernel * Renamed and refactored these so that they're no dependent on F-Curves, since all they really used was the fcu->modifiers list * Added missing license blocks to a few files
2009-07-02 05:25:14 +00:00
free_fmodifiers(&fcu->modifiers);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
F-Curve Modifiers: Cycles Modifier * Added GUI and fixed bugs in the Cycles Modifier. This replaces the old Cyclic Extrapolation settings, giving more fine-grained control over the results. You can now specify whether the keyframes are repeated before and/or after the range independently, also, the maximum number of cycles on either side can be controlled. * TODO: it would be nice to have the last value held for cyclic+offset. * Deleting modifiers now works
2009-03-17 06:37:50 +00:00
/* free f-curve itself */
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
MEM_freeN(fcu);
}
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
/* Frees a list of F-Curves */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void free_fcurves(ListBase *list)
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
{
FCurve *fcu, *fcn;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* sanity check */
if (list == NULL)
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* free data - no need to call remlink before freeing each curve,
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
* as we store reference to next, and freeing only touches the curve
* it's given
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (fcu = list->first; fcu; fcu = fcn) {
fcn = fcu->next;
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_fcurve(fcu);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* clear pointers just in case */
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
BLI_listbase_clear(list);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
}
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* ---------------------- Copy --------------------------- */
/* duplicate an F-Curve */
Make whole ID copying code use const source pointer. Noisy change, but safe, and better do it sooner than later if we are to rework copying code. Also, previous commit shows this *is* useful to catch some mistakes.
2017-06-14 22:36:30 +02:00
FCurve *copy_fcurve(const 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
{
FCurve *fcu_d;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* sanity check */
if (fcu == NULL)
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* make a copy */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu_d = MEM_dupallocN(fcu);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu_d->next = fcu_d->prev = NULL;
fcu_d->grp = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* copy curve data */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu_d->bezt = MEM_dupallocN(fcu_d->bezt);
fcu_d->fpt = MEM_dupallocN(fcu_d->fpt);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* copy rna-path */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu_d->rna_path = MEM_dupallocN(fcu_d->rna_path);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* copy driver */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu_d->driver = fcurve_copy_driver(fcu_d->driver);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* copy modifiers */
NLA SoC: Separating out F-Modifier API * F-Modifier API is now in its own file in blenkernel * Renamed and refactored these so that they're no dependent on F-Curves, since all they really used was the fcu->modifiers list * Added missing license blocks to a few files
2009-07-02 05:25:14 +00:00
copy_fmodifiers(&fcu_d->modifiers, &fcu->modifiers);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* return new data */
return fcu_d;
}
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* duplicate a list of F-Curves */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void copy_fcurves(ListBase *dst, ListBase *src)
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
{
FCurve *dfcu, *sfcu;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* sanity checks */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, dst, src))
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* clear destination list first */
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
BLI_listbase_clear(dst);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - AnimSys Data management stuff... * Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so. * Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use... * Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code). * File writing code should now only write the new data to files
2009-01-18 10:41:45 +00:00
/* copy one-by-one */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (sfcu = src->first; sfcu; sfcu = sfcu->next) {
dfcu = copy_fcurve(sfcu);
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
BLI_addtail(dst, dfcu);
}
}
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* ----------------- Finding F-Curves -------------------------- */
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
/* high level function to get an fcurve from C without having the rna */
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
FCurve *id_data_find_fcurve(ID *id, void *data, StructRNA *type, const char *prop_name, int index, bool *r_driven)
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
{
/* anim vars */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
AnimData *adt = BKE_animdata_from_id(id);
FCurve *fcu = NULL;
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
/* rna vars */
PointerRNA ptr;
PropertyRNA *prop;
char *path;
3D Audio GSoC: Implemented basic audio animation. * AnimatableProperty: Propper cache writing and spline interpolation for reading (the solution for stair steps in audio animation) * Animatable properties so far are: volume, pitch, panning * Users note: Changing the pitch of a sound results in wrong seeking, due to the resulting playback length difference. * Users note: Panning only works for mono sources, values are in the range [-2..2], this basically controls the angle of the sound, 0 is front, -1 left, 1 right and 2 and -2 are back. Typical stereo panning only supports [-1..1]. * Disabled animation of audio related ffmpeg output parameters. * Scene Audio Panel: 3D Listener settings also for Renderer, new Volume property (animatable!), Update/Bake buttons for animation problems, moved sampling rate and channel count here
2011-07-28 13:58:59 +00:00
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
if (r_driven)
*r_driven = false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
/* only use the current action ??? */
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
if (ELEM(NULL, adt, adt->action))
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
RNA_pointer_create(id, type, data, &ptr);
prop = RNA_struct_find_property(&ptr, prop_name);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
if (prop) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
path = RNA_path_from_ID_to_property(&ptr, prop);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
if (path) {
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
/* animation takes priority over drivers */
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
if ((adt->action) && (adt->action->curves.first))
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu = list_find_fcurve(&adt->action->curves, path, index);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
/* if not animated, check if driven */
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
if ((fcu == NULL) && (adt->drivers.first)) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu = list_find_fcurve(&adt->drivers, path, index);
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
if (fcu && r_driven)
*r_driven = true;
3D Audio GSoC: Implemented basic audio animation. * AnimatableProperty: Propper cache writing and spline interpolation for reading (the solution for stair steps in audio animation) * Animatable properties so far are: volume, pitch, panning * Users note: Changing the pitch of a sound results in wrong seeking, due to the resulting playback length difference. * Users note: Panning only works for mono sources, values are in the range [-2..2], this basically controls the angle of the sound, 0 is front, -1 left, 1 right and 2 and -2 are back. Typical stereo panning only supports [-1..1]. * Disabled animation of audio related ffmpeg output parameters. * Scene Audio Panel: 3D Listener settings also for Renderer, new Volume property (animatable!), Update/Bake buttons for animation problems, moved sampling rate and channel count here
2011-07-28 13:58:59 +00:00
fcu = NULL;
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
- sequencer speed effect back using fcurves, still needs manual reloading to refresh. - added a function id_data_find_fcurve() to get the fcurve without RNA vars. Aligorith: this could be made to use a path rather then a property name.
2009-11-14 14:58:19 +00:00
MEM_freeN(path);
}
}
return 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
/* Find the F-Curve affecting the given RNA-access path + index, in the list of F-Curves provided */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
FCurve *list_find_fcurve(ListBase *list, const char rna_path[], const int array_index)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
FCurve *fcu;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* sanity checks */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (ELEM(NULL, list, rna_path) || (array_index < 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
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* check paths of curves, then array indices... */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (fcu = list->first; fcu; fcu = fcu->next) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* simple string-compare (this assumes that they have the same root...) */
Cleanup: strcmp/strncmp -> STREQ/STREQLEN (in boolean usage). Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)' and 'strcmp(foo, bar) == 0' in several places...
2015-01-26 16:03:11 +01:00
if (fcu->rna_path && STREQ(fcu->rna_path, rna_path)) {
bad spelling; 'indicies' --> 'indices'
2011-01-18 01:58:19 +00:00
/* now check indices */
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
if (fcu->array_index == array_index)
return fcu;
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* return */
return NULL;
}
python function to remove drivers. eg: bpy.context.object.driver_remove("location") ANIM_remove_driver now accepts -1 as an index for removing all drivers from one path.
2010-04-11 09:13:37 +00:00
/* quick way to loop over all fcurves of a given 'path' */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
FCurve *iter_step_fcurve(FCurve *fcu_iter, const char rna_path[])
python function to remove drivers. eg: bpy.context.object.driver_remove("location") ANIM_remove_driver now accepts -1 as an index for removing all drivers from one path.
2010-04-11 09:13:37 +00:00
{
FCurve *fcu;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
python function to remove drivers. eg: bpy.context.object.driver_remove("location") ANIM_remove_driver now accepts -1 as an index for removing all drivers from one path.
2010-04-11 09:13:37 +00:00
/* sanity checks */
if (ELEM(NULL, fcu_iter, rna_path))
return NULL;
/* check paths of curves, then array indices... */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (fcu = fcu_iter; fcu; fcu = fcu->next) {
python function to remove drivers. eg: bpy.context.object.driver_remove("location") ANIM_remove_driver now accepts -1 as an index for removing all drivers from one path.
2010-04-11 09:13:37 +00:00
/* simple string-compare (this assumes that they have the same root...) */
Cleanup: strcmp/strncmp -> STREQ/STREQLEN (in boolean usage). Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)' and 'strcmp(foo, bar) == 0' in several places...
2015-01-26 16:03:11 +01:00
if (fcu->rna_path && STREQ(fcu->rna_path, rna_path)) {
python function to remove drivers. eg: bpy.context.object.driver_remove("location") ANIM_remove_driver now accepts -1 as an index for removing all drivers from one path.
2010-04-11 09:13:37 +00:00
return fcu;
}
}
/* return */
return NULL;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Get list of LinkData's containing pointers to the F-Curves which control the types of data indicated
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
* Lists...
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - dst: list of LinkData's matching the criteria returned.
* List must be freed after use, and is assumed to be empty when passed.
* - src: list of F-Curves to search through
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
* Filters...
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - dataPrefix: i.e. 'pose.bones[' or 'nodes['
* - dataName: name of entity within "" immediately following the prefix
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
int list_find_data_fcurves(ListBase *dst, ListBase *src, const char *dataPrefix, const char *dataName)
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
{
FCurve *fcu;
int matches = 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
/* sanity checks */
Defines: replace ELEM3-16 with ELEM(...), that can take varargs
2014-07-20 01:30:29 +10:00
if (ELEM(NULL, dst, src, dataPrefix, dataName))
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
return 0;
else if ((dataPrefix[0] == 0) || (dataName[0] == 0))
return 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
/* search each F-Curve one by one */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (fcu = src->first; fcu; fcu = fcu->next) {
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
/* check if quoted string matches the path */
if ((fcu->rna_path) && strstr(fcu->rna_path, dataPrefix)) {
rename BLI_getQuotedStr --> BLI_str_quoted_substrN to make it more clear its doing an allocation.
2012-07-09 22:16:50 +00:00
char *quotedName = BLI_str_quoted_substrN(fcu->rna_path, dataPrefix);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
if (quotedName) {
/* check if the quoted name matches the required name */
Cleanup: strcmp/strncmp -> STREQ/STREQLEN (in boolean usage). Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)' and 'strcmp(foo, bar) == 0' in several places...
2015-01-26 16:03:11 +01:00
if (STREQ(quotedName, dataName)) {
rename BLI_getQuotedStr --> BLI_str_quoted_substrN to make it more clear its doing an allocation.
2012-07-09 22:16:50 +00:00
LinkData *ld = MEM_callocN(sizeof(LinkData), __func__);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
ld->data = fcu;
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
BLI_addtail(dst, ld);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
matches++;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
/* always free the quoted string, since it needs freeing */
MEM_freeN(quotedName);
}
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
/* return the number of matches */
return matches;
}
Cleanup: use prefix for return args
2016-03-24 18:05:10 +11:00
FCurve *rna_get_fcurve(
PointerRNA *ptr, PropertyRNA *prop, int rnaindex,
AnimData **r_adt, bAction **r_action, bool *r_driven, bool *r_special)
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
{
Cleanup: use prefix for return args
2016-03-24 18:05:10 +11:00
return rna_get_fcurve_context_ui(NULL, ptr, prop, rnaindex, r_adt, r_action, r_driven, r_special);
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
}
Cleanup: use prefix for return args
2016-03-24 18:05:10 +11:00
FCurve *rna_get_fcurve_context_ui(
bContext *C, PointerRNA *ptr, PropertyRNA *prop, int rnaindex,
AnimData **r_animdata, bAction **r_action, bool *r_driven, bool *r_special)
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
FCurve *fcu = NULL;
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
PointerRNA tptr = *ptr;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
*r_driven = false;
Keyframes on NLA-Strip F-Curves are detected by RNA buttons too
2014-01-24 17:09:21 +13:00
*r_special = false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Cleanup: use prefix for return args
2016-03-24 18:05:10 +11:00
if (r_animdata) *r_animdata = NULL;
if (r_action) *r_action = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix T45864: Wrong NLA Control Curves keyed when using the Graph Editor sliders This commit simplifies the logic for finding the control curves for NLA strips, thus eliminating a whole bunch of weird errors that were happening here. It should also fix a number of other related issues here.
2015-08-22 02:33:31 +12:00
/* Special case for NLA Control Curves... */
Fix T46163: NLA properties with drivers aren't displayed as having drivers While such drivers will generally get evaluated too late to be of much use during animations, it can still be useful to allow using drivers to control a whole bunch of NLA strip properties (i.e. syncing NLA strip timings via a single property/control). Keyframe insertion however is still not allowed on these properties (and an error message will now be displayed when trying to do so, instead of silently failing), as it is useless.
2017-10-20 17:04:57 +13:00
if (BKE_nlastrip_has_curves_for_property(ptr, prop)) {
Fix T45864: Wrong NLA Control Curves keyed when using the Graph Editor sliders This commit simplifies the logic for finding the control curves for NLA strips, thus eliminating a whole bunch of weird errors that were happening here. It should also fix a number of other related issues here.
2015-08-22 02:33:31 +12:00
NlaStrip *strip = (NlaStrip *)ptr->data;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix T45864: Wrong NLA Control Curves keyed when using the Graph Editor sliders This commit simplifies the logic for finding the control curves for NLA strips, thus eliminating a whole bunch of weird errors that were happening here. It should also fix a number of other related issues here.
2015-08-22 02:33:31 +12:00
/* Set the special flag, since it cannot be a normal action/driver
* if we've been told to start looking here...
*/
*r_special = true;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix T45864: Wrong NLA Control Curves keyed when using the Graph Editor sliders This commit simplifies the logic for finding the control curves for NLA strips, thus eliminating a whole bunch of weird errors that were happening here. It should also fix a number of other related issues here.
2015-08-22 02:33:31 +12:00
/* The F-Curve either exists or it doesn't here... */
fcu = list_find_fcurve(&strip->fcurves, RNA_property_identifier(prop), rnaindex);
return fcu;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
/* there must be some RNA-pointer + property combon */
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
if (prop && tptr.id.data && RNA_property_animateable(&tptr, prop)) {
AnimData *adt = BKE_animdata_from_id(tptr.id.data);
Fix Cycles crashing with previous own commit. Behavior with NULL context was wrong.
2014-10-06 18:00:56 +02:00
int step = C ? 2 : 1; /* Always 1 in case we have no context (can't check in 'ancestors' of given RNA ptr). */
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
char *path = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix Cycles crashing with previous own commit. Behavior with NULL context was wrong.
2014-10-06 18:00:56 +02:00
if (!adt && C) {
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
path = BKE_animdata_driver_path_hack(C, &tptr, prop, NULL);
adt = BKE_animdata_from_id(tptr.id.data);
step--;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix T45864: Wrong NLA Control Curves keyed when using the Graph Editor sliders This commit simplifies the logic for finding the control curves for NLA strips, thus eliminating a whole bunch of weird errors that were happening here. It should also fix a number of other related issues here.
2015-08-22 02:33:31 +12:00
/* Standard F-Curve - Animation (Action) or Drivers */
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
while (adt && step--) {
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
if ((adt->action && adt->action->curves.first) || (adt->drivers.first)) {
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
/* XXX this function call can become a performance bottleneck */
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
if (step) {
path = RNA_path_from_ID_to_property(&tptr, prop);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframes on NLA-Strip F-Curves are detected by RNA buttons too
2014-01-24 17:09:21 +13:00
// XXX: the logic here is duplicated with a function up above
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
if (path) {
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
/* animation takes priority over drivers */
Code Cleanup / Preemptive Bug Fixing: "action" parameter may get set when it shouldn't be Logically, it makes sense that this parameter only gets used to describe the action that the F-Curve actually belongs to (if it belongs to one). Otherwise, it should not be set at all.
2014-01-24 16:10:26 +13:00
if (adt->action && adt->action->curves.first) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu = list_find_fcurve(&adt->action->curves, path, rnaindex);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Cleanup: use prefix for return args
2016-03-24 18:05:10 +11:00
if (fcu && r_action)
*r_action = adt->action;
Code Cleanup / Preemptive Bug Fixing: "action" parameter may get set when it shouldn't be Logically, it makes sense that this parameter only gets used to describe the action that the F-Curve actually belongs to (if it belongs to one). Otherwise, it should not be set at all.
2014-01-24 16:10:26 +13:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
/* if not animated, check if driven */
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
if (!fcu && (adt->drivers.first)) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu = list_find_fcurve(&adt->drivers, path, rnaindex);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix T41525: Button keyframe indicators don't work correctly when editing NLA Strips When the active action is a NLA strip, the keyframe indicator colors for buttons and the 3D view indicator (i.e. the current frame indicator changes color) didn't work correctly. This was because they were still checking for keyframes in "global" time space, whereas they needed to be applying NLA corrections to "look inside" the remapped action.
2014-11-16 20:24:38 +13:00
if (fcu) {
Cleanup: use prefix for return args
2016-03-24 18:05:10 +11:00
if (r_animdata) *r_animdata = adt;
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
*r_driven = true;
Bugfix T41525: Button keyframe indicators don't work correctly when editing NLA Strips When the active action is a NLA strip, the keyframe indicator colors for buttons and the 3D view indicator (i.e. the current frame indicator changes color) didn't work correctly. This was because they were still checking for keyframes in "global" time space, whereas they needed to be applying NLA corrections to "look inside" the remapped action.
2014-11-16 20:24:38 +13:00
}
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Cleanup: use prefix for return args
2016-03-24 18:05:10 +11:00
if (fcu && r_action) {
if (r_animdata) *r_animdata = adt;
*r_action = adt->action;
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
break;
}
else if (step) {
char *tpath = BKE_animdata_driver_path_hack(C, &tptr, prop, path);
if (tpath && tpath != path) {
MEM_freeN(path);
path = tpath;
adt = BKE_animdata_from_id(tptr.id.data);
}
else {
adt = NULL;
}
}
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
}
}
}
Fix T40350: Some texture prop did not have visual feedback they were driven. This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still not work in those cases... Better that than nothing, though. Thanks to Campbell for review.
2014-10-06 17:03:19 +02:00
MEM_SAFE_FREE(path);
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix [#20773] NODE ANIMATION: Animating node values broken Now the compositing node tree will update on frame change if any of the nodes are animated. This doesn't work for playback (i.e. alt a), that's better off waiting until we have some kind of frame caching system.
2010-01-27 05:42:17 +00:00
return fcu;
}
Assorted F-Curve/Keyframe API stuff (for use with some Sequencer editing): * Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips. * Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
2009-12-22 10:14:13 +00:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* ----------------- Finding Keyframes/Extents -------------------------- */
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
/* Binary search algorithm for finding where to insert BezTriple, with optional argument for precision required.
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
* Returns the index to insert at (data already at that index will be offset if replace is 0)
*/
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
static int binarysearch_bezt_index_ex(BezTriple array[], float frame, int arraylen, float threshold, bool *r_replace)
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
int start = 0, end = arraylen;
int loopbreaker = 0, maxloop = arraylen * 2;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup - spelling - turns out we had tessellation spelt wrong all over. - use \directive for doxy (not @directive) - remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
2012-03-02 16:05:54 +00:00
/* initialize replace-flag first */
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
*r_replace = false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: also spelling
2012-08-24 23:22:34 +00:00
/* sneaky optimizations (don't go through searching process if...):
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - keyframe to be added is to be added out of current bounds
* - keyframe to be added would replace one of the existing ones on bounds
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
*/
if ((arraylen <= 0) || (array == NULL)) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_WARN(&LOG, "encountered invalid array");
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
return 0;
}
else {
/* check whether to add before/after/on */
float framenum;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
/* 'First' Keyframe (when only one keyframe, this case is used) */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
framenum = array[0].vec[1][0];
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
if (IS_EQT(frame, framenum, threshold)) {
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
*r_replace = true;
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
return 0;
}
else if (frame < framenum)
return 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
/* 'Last' Keyframe */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
framenum = array[(arraylen - 1)].vec[1][0];
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
if (IS_EQT(frame, framenum, threshold)) {
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
*r_replace = true;
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
return (arraylen - 1);
}
else if (frame > framenum)
return arraylen;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
/* most of the time, this loop is just to find where to put it
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
* 'loopbreaker' is just here to prevent infinite loops
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (loopbreaker = 0; (start <= end) && (loopbreaker < maxloop); loopbreaker++) {
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
/* compute and get midpoint */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
int mid = start + ((end - start) / 2); /* we calculate the midpoint this way to avoid int overflows... */
float midfra = array[mid].vec[1][0];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
/* check if exactly equal to midpoint */
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
if (IS_EQT(frame, midfra, threshold)) {
use const pointers for file loading and booleans for animation system return values passed as pointers.
2013-03-17 19:13:04 +00:00
*r_replace = true;
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
return mid;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
/* repeat in upper/lower half */
if (frame > midfra)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
start = mid + 1;
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
else if (frame < midfra)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
end = mid - 1;
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
/* print error if loop-limit exceeded */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (loopbreaker == (maxloop - 1)) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "search taking too long");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup
2012-07-07 22:51:57 +00:00
/* include debug info */
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "\tround = %d: start = %d, end = %d, arraylen = %d", loopbreaker, start, end, arraylen);
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5 - Pose Enhancement Tools This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'. Be aware that this commit is just the initial starting point, with some parts yet to be done. A short description of these tools follows: * Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it * Push Pose (Ctrl-E) - exaggerates the current pose * Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown. Todo's: * Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached. * Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later. * Figure out why breakdown breaks down
2009-09-19 00:18:42 +00:00
/* not found, so return where to place it */
return start;
}
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
/* Binary search algorithm for finding where to insert BezTriple. (for use by insert_bezt_fcurve)
* Returns the index to insert at (data already at that index will be offset if replace is 0)
*/
int binarysearch_bezt_index(BezTriple array[], float frame, int arraylen, bool *r_replace)
{
/* this is just a wrapper which uses the default threshold */
return binarysearch_bezt_index_ex(array, frame, arraylen, BEZT_BINARYSEARCH_THRESH, r_replace);
}
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
/* ...................................... */
/* helper for calc_fcurve_* functions -> find first and last BezTriple to be used */
Bugfix [#32331] Graph editor zoom to selected includes coordinate origin if more than one curve is displayed The range calculation used to use a fixed 0-1 range whenever it couldn't find any values for a particular F-Curve. However, this was then taken by the aggregation calculation to be used as just another value, leading to problems if only vertices of a very high-value curve are selected to be included. Modified the range calculation to ensure that suitable vertices were found before trying to take the range values returned.
2012-08-18 04:39:15 +00:00
static short get_fcurve_end_keyframes(FCurve *fcu, BezTriple **first, BezTriple **last,
Code cleanup: use bools where possible
2014-02-03 18:55:59 +11:00
const bool do_sel_only)
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
{
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
bool found = false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
/* init outputs */
*first = NULL;
*last = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
/* sanity checks */
if (fcu->bezt == NULL)
Bugfix [#32331] Graph editor zoom to selected includes coordinate origin if more than one curve is displayed The range calculation used to use a fixed 0-1 range whenever it couldn't find any values for a particular F-Curve. However, this was then taken by the aggregation calculation to be used as just another value, leading to problems if only vertices of a very high-value curve are selected to be included. Modified the range calculation to ensure that suitable vertices were found before trying to take the range values returned.
2012-08-18 04:39:15 +00:00
return found;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
/* only include selected items? */
remove $Id: tags after discussion on the mailign list: http://markmail.org/message/fp7ozcywxum3ar7n
2011-10-23 17:52:20 +00:00
if (do_sel_only) {
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
BezTriple *bezt;
unsigned int i;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
/* find first selected */
bezt = fcu->bezt;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (i = 0; i < fcu->totvert; bezt++, i++) {
Curve selection, de-duplicate & cleanup
2015-07-09 14:31:27 +10:00
if (BEZT_ISSEL_ANY(bezt)) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
*first = bezt;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
found = true;
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
break;
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
/* find last selected */
Code cleanup: remove redundant arg from ARRAY_LAST_ITEM
2014-05-29 13:38:34 +10:00
bezt = ARRAY_LAST_ITEM(fcu->bezt, BezTriple, fcu->totvert);
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (i = 0; i < fcu->totvert; bezt--, i++) {
Curve selection, de-duplicate & cleanup
2015-07-09 14:31:27 +10:00
if (BEZT_ISSEL_ANY(bezt)) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
*last = bezt;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
found = true;
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
break;
}
}
}
else {
/* just full array */
*first = fcu->bezt;
Code cleanup: remove redundant arg from ARRAY_LAST_ITEM
2014-05-29 13:38:34 +10:00
*last = ARRAY_LAST_ITEM(fcu->bezt, BezTriple, fcu->totvert);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
found = true;
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#32331] Graph editor zoom to selected includes coordinate origin if more than one curve is displayed The range calculation used to use a fixed 0-1 range whenever it couldn't find any values for a particular F-Curve. However, this was then taken by the aggregation calculation to be used as just another value, leading to problems if only vertices of a very high-value curve are selected to be included. Modified the range calculation to ensure that suitable vertices were found before trying to take the range values returned.
2012-08-18 04:39:15 +00:00
return found;
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
}
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
/* Calculate the extents of F-Curve's data */
Code cleanup: use bools where possible
2014-02-03 18:55:59 +11:00
bool calc_fcurve_bounds(FCurve *fcu, float *xmin, float *xmax, float *ymin, float *ymax,
const bool do_sel_only, const bool include_handles)
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
float xminv = 999999999.0f, xmaxv = -999999999.0f;
float yminv = 999999999.0f, ymaxv = -999999999.0f;
Code cleanup: use bools where possible
2014-02-03 18:55:59 +11:00
bool foundvert = false;
Animato - Support for 'BuiltIn' and 'Relative' Keying Sets When inserting keyframes in the 3D-View (support will be extended to other editors in due course) using the IKEY hotkey, the menu which appears will now consist of 3 parts: * 'Active Keying Set' - this option allows you to use the user-defined KeyingSet which is active for the current scene (i.e. the one seen in the TimeLine/Outliner headers) * User defined Keying Sets - a list of all such available KeyingSets is included, and entries can be chosen from there * Built-In Keying Sets - see later... To achieve this, several changes needed to be made first: * Added support for 'relative' in addition to 'absolute' Keying Sets. Relative Keying Sets are Keying Sets which operate on data from the current context (i.e. a 'location' KeyingSet will add location keyframes for selected objects/bones/nodes as opposed to location keyframes for some particular object). The is a tentative 'templates' requirement system here, which still needs to be fully fleshed out. * Added support for builtin Keying Sets (i.e. 'Location', 'Rotation', 'Scaling', and 'LocRot' as a few initial demonstrations), which replaces the temporary Insert Keyframe operator for the 3D-View (IKEY). These are effectively relative Keying Set definitions which are included in Blender by default and stored in a list separate from user-defined ones. Volunteer help in defining a few more of these for other editors will be welcome soon. * Removed/replaced much of the crappy temporary Keyframing operator code, though a few tweaks could still be done.
2009-03-31 22:36:13 +00:00
unsigned int i;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
if (fcu->totvert) {
if (fcu->bezt) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
BezTriple *bezt_first = NULL, *bezt_last = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
if (xmin || xmax) {
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
/* get endpoint keyframes */
Bugfix [#32331] Graph editor zoom to selected includes coordinate origin if more than one curve is displayed The range calculation used to use a fixed 0-1 range whenever it couldn't find any values for a particular F-Curve. However, this was then taken by the aggregation calculation to be used as just another value, leading to problems if only vertices of a very high-value curve are selected to be included. Modified the range calculation to ensure that suitable vertices were found before trying to take the range values returned.
2012-08-18 04:39:15 +00:00
foundvert = get_fcurve_end_keyframes(fcu, &bezt_first, &bezt_last, do_sel_only);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
if (bezt_first) {
BLI_assert(bezt_last != NULL);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor - View All/Selected now includes handles for calculating extents of F-Curves It is possible to get the old behaviour (handles excluded) by bringing up the Operator Properties (F6) while in the Graph Editor (this doesn't work elsewhere due to the context requirements of this stuff).
2012-05-24 13:52:25 +00:00
if (include_handles) {
replace MIN/MAX 3,4 with inline functions
2012-12-21 05:07:26 +00:00
xminv = min_fff(xminv, bezt_first->vec[0][0], bezt_first->vec[1][0]);
xmaxv = max_fff(xmaxv, bezt_last->vec[1][0], bezt_last->vec[2][0]);
Graph Editor - View All/Selected now includes handles for calculating extents of F-Curves It is possible to get the old behaviour (handles excluded) by bringing up the Operator Properties (F6) while in the Graph Editor (this doesn't work elsewhere due to the context requirements of this stuff).
2012-05-24 13:52:25 +00:00
}
else {
rename api functions... - minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
2012-10-23 13:28:22 +00:00
xminv = min_ff(xminv, bezt_first->vec[1][0]);
xmaxv = max_ff(xmaxv, bezt_last->vec[1][0]);
Graph Editor - View All/Selected now includes handles for calculating extents of F-Curves It is possible to get the old behaviour (handles excluded) by bringing up the Operator Properties (F6) while in the Graph Editor (this doesn't work elsewhere due to the context requirements of this stuff).
2012-05-24 13:52:25 +00:00
}
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
}
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
/* only loop over keyframes to find extents for values if needed */
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
if (ymin || ymax) {
Bugfix T41042: Irrelevant Bezier handles still affect Graph Editor Show All The "Show All" and "Show Selected" operators in the Graph Editor was taking into account all handles on keyframes, even when some of those would be invalid and/or set to nonsense values (e.g. for any interpolation mode other than "Bezier")
2014-07-20 19:22:22 +12:00
BezTriple *bezt, *prevbezt = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix T41042: Irrelevant Bezier handles still affect Graph Editor Show All The "Show All" and "Show Selected" operators in the Graph Editor was taking into account all handles on keyframes, even when some of those would be invalid and/or set to nonsense values (e.g. for any interpolation mode other than "Bezier")
2014-07-20 19:22:22 +12:00
for (bezt = fcu->bezt, i = 0; i < fcu->totvert; prevbezt = bezt, bezt++, i++) {
Curve selection, de-duplicate & cleanup
2015-07-09 14:31:27 +10:00
if ((do_sel_only == false) || BEZT_ISSEL_ANY(bezt)) {
Bugfix T41042: Irrelevant Bezier handles still affect Graph Editor Show All The "Show All" and "Show Selected" operators in the Graph Editor was taking into account all handles on keyframes, even when some of those would be invalid and/or set to nonsense values (e.g. for any interpolation mode other than "Bezier")
2014-07-20 19:22:22 +12:00
/* keyframe itself */
yminv = min_ff(yminv, bezt->vec[1][1]);
ymaxv = max_ff(ymaxv, bezt->vec[1][1]);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor - View All/Selected now includes handles for calculating extents of F-Curves It is possible to get the old behaviour (handles excluded) by bringing up the Operator Properties (F6) while in the Graph Editor (this doesn't work elsewhere due to the context requirements of this stuff).
2012-05-24 13:52:25 +00:00
if (include_handles) {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* left handle - only if applicable
Bugfix T41042: Irrelevant Bezier handles still affect Graph Editor Show All The "Show All" and "Show Selected" operators in the Graph Editor was taking into account all handles on keyframes, even when some of those would be invalid and/or set to nonsense values (e.g. for any interpolation mode other than "Bezier")
2014-07-20 19:22:22 +12:00
* NOTE: for the very first keyframe, the left handle actually has no bearings on anything
*/
if (prevbezt && (prevbezt->ipo == BEZT_IPO_BEZ)) {
yminv = min_ff(yminv, bezt->vec[0][1]);
ymaxv = max_ff(ymaxv, bezt->vec[0][1]);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix T41042: Irrelevant Bezier handles still affect Graph Editor Show All The "Show All" and "Show Selected" operators in the Graph Editor was taking into account all handles on keyframes, even when some of those would be invalid and/or set to nonsense values (e.g. for any interpolation mode other than "Bezier")
2014-07-20 19:22:22 +12:00
/* right handle - only if applicable */
if (bezt->ipo == BEZT_IPO_BEZ) {
yminv = min_ff(yminv, bezt->vec[2][1]);
Bugfix T41240: Home key doesn't show everything on F-Curves Own copy and paste typo in 73d157e meant that this was not in some cases, the bounds calculated may be incorrect.
2014-07-30 18:15:49 +12:00
ymaxv = max_ff(ymaxv, bezt->vec[2][1]);
Bugfix T41042: Irrelevant Bezier handles still affect Graph Editor Show All The "Show All" and "Show Selected" operators in the Graph Editor was taking into account all handles on keyframes, even when some of those would be invalid and/or set to nonsense values (e.g. for any interpolation mode other than "Bezier")
2014-07-20 19:22:22 +12:00
}
Graph Editor - View All/Selected now includes handles for calculating extents of F-Curves It is possible to get the old behaviour (handles excluded) by bringing up the Operator Properties (F6) while in the Graph Editor (this doesn't work elsewhere due to the context requirements of this stuff).
2012-05-24 13:52:25 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
foundvert = true;
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
}
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
}
}
}
else if (fcu->fpt) {
/* frame range can be directly calculated from end verts */
if (xmin || xmax) {
rename api functions... - minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
2012-10-23 13:28:22 +00:00
xminv = min_ff(xminv, fcu->fpt[0].vec[0]);
xmaxv = max_ff(xmaxv, fcu->fpt[fcu->totvert - 1].vec[0]);
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
/* only loop over keyframes to find extents for values if needed */
if (ymin || ymax) {
FPoint *fpt;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (fpt = fcu->fpt, i = 0; i < fcu->totvert; fpt++, i++) {
Graph Editor Bugfix: 'HomeKey' (View All) wasn't correctly calculating y-extents It was only using the y-extents of the last F-Curve it encountered
2009-05-11 11:51:30 +00:00
if (fpt->vec[1] < yminv)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
yminv = fpt->vec[1];
Graph Editor Bugfix: 'HomeKey' (View All) wasn't correctly calculating y-extents It was only using the y-extents of the last F-Curve it encountered
2009-05-11 11:51:30 +00:00
if (fpt->vec[1] > ymaxv)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
ymaxv = fpt->vec[1];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
foundvert = true;
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
}
}
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
if (foundvert) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (xmin) *xmin = xminv;
if (xmax) *xmax = xmaxv;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (ymin) *ymin = yminv;
if (ymax) *ymax = ymaxv;
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
}
else {
move debug flag into its own global var (G.debug), split up debug options. --debug --debug-ffmpeg --debug-python --debug-events --debug-wm This makes debug output easier to read - event debug prints would flood output too much before. For convenience: --debug-all turns all debug flags on (works as --debug did before). also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
2012-03-31 00:59:17 +00:00
if (G.debug & G_DEBUG)
Bugfix [#25617] HOME Key in fcurve editor doesn't center properly * When euler-rotation F-Curves had a single keyframe only, the view would be artifically extended to fill up to 57 (this comes from the radians to degrees calculations) due to a combination of the bounds- finding function enforcing a minimum separation of 1 unit between min/max. This has now been moved to the operator-level where it gets applied AFTER these conversions have taken effect * F-Curves with samples only (i.e. baked F-Curves) would be ignored by these operators. Was caused by using a poll calback that only considered whether there were keyframes. Hopefully this is sufficient; otherwise a hybrid poll method will be needed.
2011-01-14 05:19:04 +00:00
printf("F-Curve calc bounds didn't find anything, so assuming minimum bounds of 1.0\n");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (xmin) *xmin = 0.0f;
if (xmax) *xmax = 1.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (ymin) *ymin = 0.0f;
if (ymax) *ymax = 1.0f;
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#32331] Graph editor zoom to selected includes coordinate origin if more than one curve is displayed The range calculation used to use a fixed 0-1 range whenever it couldn't find any values for a particular F-Curve. However, this was then taken by the aggregation calculation to be used as just another value, leading to problems if only vertices of a very high-value curve are selected to be included. Modified the range calculation to ensure that suitable vertices were found before trying to take the range values returned.
2012-08-18 04:39:15 +00:00
return foundvert;
Graph Editor: Restoring 'View All' (HomeKey) and Auto-Set Preview Range ('Ctrl Alt P')
2009-02-10 10:42:04 +00:00
}
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
/* Calculate the extents of F-Curve's keyframes */
fix for action editor view-selected behaving strangely. - when an fcurve had no selected keyframes, a default fallback value was used which caused view-selected to include frame 1, even when no selected frames were there. - the vertical axis was always reset, ideally we would center vertically too but the way this operator currently works we only know about the frame range, now don't change the vertical scroll when viewing selected since it would always jump to the top of the screen (view-all still acts this way).
2013-07-18 02:59:28 +00:00
bool calc_fcurve_range(FCurve *fcu, float *start, float *end,
Code cleanup: use bools where possible
2014-02-03 18:55:59 +11:00
const bool do_sel_only, const bool do_min_length)
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
float min = 999999999.0f, max = -999999999.0f;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
bool foundvert = false;
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
if (fcu->totvert) {
if (fcu->bezt) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
BezTriple *bezt_first = NULL, *bezt_last = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
/* get endpoint keyframes */
remove $Id: tags after discussion on the mailign list: http://markmail.org/message/fp7ozcywxum3ar7n
2011-10-23 17:52:20 +00:00
get_fcurve_end_keyframes(fcu, &bezt_first, &bezt_last, do_sel_only);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
if (bezt_first) {
BLI_assert(bezt_last != NULL);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
rename api functions... - minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
2012-10-23 13:28:22 +00:00
min = min_ff(min, bezt_first->vec[1][0]);
max = max_ff(max, bezt_last->vec[1][0]);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
foundvert = true;
Bugfix [#26505] zoom in selected keys on graph editor Not really a "bug", but it was on my todo anyways. Based on patch [#26508] by Campbell, with a few modifications including extending this to the Action/DopeSheet editor too.
2011-03-17 10:02:37 +00:00
}
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
}
else if (fcu->fpt) {
rename api functions... - minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
2012-10-23 13:28:22 +00:00
min = min_ff(min, fcu->fpt[0].vec[0]);
max = max_ff(max, fcu->fpt[fcu->totvert - 1].vec[0]);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
foundvert = true;
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
if (foundvert == false) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
min = max = 0.0f;
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
}
remove $Id: tags after discussion on the mailign list: http://markmail.org/message/fp7ozcywxum3ar7n
2011-10-23 17:52:20 +00:00
if (do_min_length) {
/* minimum length is 1 frame */
if (min == max) {
max += 1.0f;
}
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
}
remove $Id: tags after discussion on the mailign list: http://markmail.org/message/fp7ozcywxum3ar7n
2011-10-23 17:52:20 +00:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
*start = min;
*end = max;
fix for action editor view-selected behaving strangely. - when an fcurve had no selected keyframes, a default fallback value was used which caused view-selected to include frame 1, even when no selected frames were there. - the vertical axis was always reset, ideally we would center vertically too but the way this operator currently works we only know about the frame range, now don't change the vertical scroll when viewing selected since it would always jump to the top of the screen (view-all still acts this way).
2013-07-18 02:59:28 +00:00
return foundvert;
Animato - More work on Action Editor * Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents) * Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way. * Fixed crashes when selecting keyframes in 'object' summary channels * Removed prototypes for a few unused/depreceated functions...
2009-01-20 11:56:45 +00:00
}
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* ----------------- Status Checks -------------------------- */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Are keyframes on F-Curve of any use?
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
* Usability of keyframes refers to whether they should be displayed,
* and also whether they will have any influence on the final result.
*/
Code cleanup: use bools where possible
2014-02-03 18:55:59 +11:00
bool fcurve_are_keyframes_usable(FCurve *fcu)
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
{
/* F-Curve must exist */
if (fcu == NULL)
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* F-Curve must not have samples - samples are mutually exclusive of keyframes */
if (fcu->fpt)
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* if it has modifiers, none of these should "drastically" alter the curve */
if (fcu->modifiers.first) {
FModifier *fcm;
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* check modifiers from last to first, as last will be more influential */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: optionally, only check modifier if it is the active one... */
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
for (fcm = fcu->modifiers.last; fcm; fcm = fcm->prev) {
/* ignore if muted/disabled */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (fcm->flag & (FMODIFIER_FLAG_DISABLED | FMODIFIER_FLAG_MUTED))
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
continue;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* type checks */
switch (fcm->type) {
/* clearly harmless - do nothing */
case FMODIFIER_TYPE_CYCLES:
case FMODIFIER_TYPE_STEPPED:
case FMODIFIER_TYPE_NOISE:
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* sometimes harmful - depending on whether they're "additive" or not */
case FMODIFIER_TYPE_GENERATOR:
{
FMod_Generator *data = (FMod_Generator *)fcm->data;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
if ((data->flag & FCM_GENERATOR_ADDITIVE) == 0)
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return false;
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
}
case FMODIFIER_TYPE_FN_GENERATOR:
{
FMod_FunctionGenerator *data = (FMod_FunctionGenerator *)fcm->data;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
if ((data->flag & FCM_GENERATOR_ADDITIVE) == 0)
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return false;
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
}
/* always harmful - cannot allow */
default:
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return false;
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
}
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* keyframes are usable */
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return true;
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
}
fix [#36919] Cannot delete keyframe of animated simulation parameter if simulation has been disabled
2013-10-02 16:37:47 +00:00
bool BKE_fcurve_is_protected(FCurve *fcu)
{
return ((fcu->flag & FCURVE_PROTECTED) ||
((fcu->grp) && (fcu->grp->flag & AGRP_PROTECTED)));
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Can keyframes be added to F-Curve?
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
* Keyframes can only be added if they are already visible
*/
fix [#36919] Cannot delete keyframe of animated simulation parameter if simulation has been disabled
2013-10-02 16:37:47 +00:00
bool fcurve_is_keyframable(FCurve *fcu)
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
{
/* F-Curve's keyframes must be "usable" (i.e. visible + have an effect on final result) */
if (fcurve_are_keyframes_usable(fcu) == 0)
fix [#36919] Cannot delete keyframe of animated simulation parameter if simulation has been disabled
2013-10-02 16:37:47 +00:00
return false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* F-Curve must currently be editable too */
fix [#36919] Cannot delete keyframe of animated simulation parameter if simulation has been disabled
2013-10-02 16:37:47 +00:00
if (BKE_fcurve_is_protected(fcu))
return false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
/* F-Curve is keyframable */
fix [#36919] Cannot delete keyframe of animated simulation parameter if simulation has been disabled
2013-10-02 16:37:47 +00:00
return true;
Keyframing Operators: Improved Error Messages * Keyframing operators now use the reports system for displaying all its error messages. - The benefit of this is that users no longer need to check the console for error messages if keyframing fails. - Unfortunately, reports are not currently viewable in any space/view in Blender, so... * Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed. This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain. * Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
2010-11-17 12:02:36 +00:00
}
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* ***************************** Keyframe Column Tools ********************************* */
/* add a BezTriple to a column */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void bezt_add_to_cfra_elem(ListBase *lb, BezTriple *bezt)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
CfraElem *ce, *cen;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (ce = lb->first; ce; ce = ce->next) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* double key? */
bezt_add_to_cfra_elem() - Use same keyframe equality test as in other places This shouldn't affect anything currently, as this function doesn't appear to get used anywhere.
2018-02-15 17:40:19 +13:00
if (IS_EQT(ce->cfra, bezt->vec[1][0], BEZT_BINARYSEARCH_THRESH)) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (bezt->f2 & SELECT) ce->sel = bezt->f2;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
return;
}
/* should key be inserted before this column? */
else if (ce->cfra > bezt->vec[1][0]) break;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* create a new column */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cen = MEM_callocN(sizeof(CfraElem), "add_to_cfra_elem");
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
if (ce) BLI_insertlinkbefore(lb, ce, cen);
else BLI_addtail(lb, cen);
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cen->cfra = bezt->vec[1][0];
cen->sel = bezt->f2;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
/* ***************************** Samples Utilities ******************************* */
/* Some utilities for working with FPoints (i.e. 'sampled' animation curve data, such as
fix spelling mistakes in comments (and in some python error messages), nothing to effect translations.
2011-10-17 06:39:13 +00:00
* data imported from BVH/Mocap files), which are specialized for use with high density datasets,
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
* which BezTriples/Keyframe data are ill equipped to do.
*/
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Basic sampling callback which acts as a wrapper for evaluate_fcurve()
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* 'data' arg here is unneeded here...
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
float fcurve_samplingcb_evalcurve(FCurve *fcu, void *UNUSED(data), float evaltime)
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
{
/* assume any interference from drivers on the curve is intended... */
return evaluate_fcurve(fcu, evaltime);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
}
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Main API function for creating a set of sampled curve data, given some callback function
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
* used to retrieve the values to store.
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void fcurve_store_samples(FCurve *fcu, void *data, int start, int end, FcuSampleFunc sample_cb)
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
{
FPoint *fpt, *new_fpt;
int cfra;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
/* sanity checks */
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
/* TODO: make these tests report errors using reports not CLOG's */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, fcu, sample_cb)) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "No F-Curve with F-Curve Modifiers to Bake");
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
return;
}
FCurve RNA API: add funcs to convert to samples/to keyframes. So far, we had an operator to 'bake' keyframe curves into samples, but no way to make the fcurve editable again (i.e. to convert it back into a keyframes one). Needed to fix mocap addon (see T43259). Also, fixed a glitch in `fcurve_store_samples()`, since given end frame is included in range, it is valid to give same start and end frame (in case you want a single point in samples, not much practical cases, but...).
2015-01-16 16:12:03 +01:00
if (start > end) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "Error: Frame range for Sampled F-Curve creation is inappropriate");
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
return;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
/* set up sample data */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fpt = new_fpt = MEM_callocN(sizeof(FPoint) * (end - start + 1), "FPoint Samples");
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
/* use the sampling callback at 1-frame intervals from start to end frames */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (cfra = start; cfra <= end; cfra++, fpt++) {
fpt->vec[0] = (float)cfra;
fpt->vec[1] = sample_cb(fcu, data, (float)cfra);
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
/* free any existing sample/keyframe data on curve */
if (fcu->bezt) MEM_freeN(fcu->bezt);
if (fcu->fpt) MEM_freeN(fcu->fpt);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27:31 +00:00
/* store the samples */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu->bezt = NULL;
fcu->fpt = new_fpt;
fcu->totvert = end - start + 1;
Graph Editor: Added operator to 'bake' keyframe-based F-Curves to be composed of samples. This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
2009-03-01 11:27: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
/* ***************************** F-Curve Sanity ********************************* */
/* The functions here are used in various parts of Blender, usually after some editing
* of keyframe data has occurred. They ensure that keyframe data is properly ordered and
Cleanup: trailing whitespace (comment blocks) Strip unindented comment blocks - mainly headers to avoid conflicts.
2018-06-01 18:19:39 +02:00
* that the handles are correctly
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
Add an option to do keyframe insertion in a cycle-aware fashion. When enabled, inserting keyframes into F-Curves with simple cyclic extrapolation (the same conditions as required for cycle-aware auto handle smoothing to activate) will take the cycle into account: - Keyframes that are being inserted outside of the cycle bounds are remapped to be inside the cycle. Thus it is not necessary to be within the main iteration of the cycle when tweaking. This becomes especially useful in the final animation tweaking phase when the channel keys may be staggered for overlap, so the actual master period is different for different channels. - Modifying one of the end points of a cycle also changes the other end point when appropriate, to preserve smooth transition. This feature applies to both manual keyframe insertion using 'I', and auto-keyframing. Differential Revision: https://developer.blender.org/D3140
2018-10-14 13:04:34 +03:00
/* Checks if the F-Curve has a Cycles modifier, and returns the type of the cycle behavior. */
eFCU_Cycle_Type BKE_fcurve_get_cycle_type(FCurve *fcu)
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
{
FModifier *fcm = fcu->modifiers.first;
Add an option to do keyframe insertion in a cycle-aware fashion. When enabled, inserting keyframes into F-Curves with simple cyclic extrapolation (the same conditions as required for cycle-aware auto handle smoothing to activate) will take the cycle into account: - Keyframes that are being inserted outside of the cycle bounds are remapped to be inside the cycle. Thus it is not necessary to be within the main iteration of the cycle when tweaking. This becomes especially useful in the final animation tweaking phase when the channel keys may be staggered for overlap, so the actual master period is different for different channels. - Modifying one of the end points of a cycle also changes the other end point when appropriate, to preserve smooth transition. This feature applies to both manual keyframe insertion using 'I', and auto-keyframing. Differential Revision: https://developer.blender.org/D3140
2018-10-14 13:04:34 +03:00
if (!fcm || fcm->type != FMODIFIER_TYPE_CYCLES) {
return FCU_CYCLE_NONE;
}
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
Add an option to do keyframe insertion in a cycle-aware fashion. When enabled, inserting keyframes into F-Curves with simple cyclic extrapolation (the same conditions as required for cycle-aware auto handle smoothing to activate) will take the cycle into account: - Keyframes that are being inserted outside of the cycle bounds are remapped to be inside the cycle. Thus it is not necessary to be within the main iteration of the cycle when tweaking. This becomes especially useful in the final animation tweaking phase when the channel keys may be staggered for overlap, so the actual master period is different for different channels. - Modifying one of the end points of a cycle also changes the other end point when appropriate, to preserve smooth transition. This feature applies to both manual keyframe insertion using 'I', and auto-keyframing. Differential Revision: https://developer.blender.org/D3140
2018-10-14 13:04:34 +03:00
if (fcm->flag & (FMODIFIER_FLAG_DISABLED | FMODIFIER_FLAG_MUTED)) {
return FCU_CYCLE_NONE;
}
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
Add an option to do keyframe insertion in a cycle-aware fashion. When enabled, inserting keyframes into F-Curves with simple cyclic extrapolation (the same conditions as required for cycle-aware auto handle smoothing to activate) will take the cycle into account: - Keyframes that are being inserted outside of the cycle bounds are remapped to be inside the cycle. Thus it is not necessary to be within the main iteration of the cycle when tweaking. This becomes especially useful in the final animation tweaking phase when the channel keys may be staggered for overlap, so the actual master period is different for different channels. - Modifying one of the end points of a cycle also changes the other end point when appropriate, to preserve smooth transition. This feature applies to both manual keyframe insertion using 'I', and auto-keyframing. Differential Revision: https://developer.blender.org/D3140
2018-10-14 13:04:34 +03:00
if (fcm->flag & (FMODIFIER_FLAG_RANGERESTRICT | FMODIFIER_FLAG_USEINFLUENCE)) {
return FCU_CYCLE_NONE;
}
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
Cleanup: style
2017-11-01 11:56:56 +11:00
FMod_Cycles *data = (FMod_Cycles *)fcm->data;
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
Add an option to do keyframe insertion in a cycle-aware fashion. When enabled, inserting keyframes into F-Curves with simple cyclic extrapolation (the same conditions as required for cycle-aware auto handle smoothing to activate) will take the cycle into account: - Keyframes that are being inserted outside of the cycle bounds are remapped to be inside the cycle. Thus it is not necessary to be within the main iteration of the cycle when tweaking. This becomes especially useful in the final animation tweaking phase when the channel keys may be staggered for overlap, so the actual master period is different for different channels. - Modifying one of the end points of a cycle also changes the other end point when appropriate, to preserve smooth transition. This feature applies to both manual keyframe insertion using 'I', and auto-keyframing. Differential Revision: https://developer.blender.org/D3140
2018-10-14 13:04:34 +03:00
if (data && data->after_cycles == 0 && data->before_cycles == 0) {
if (data->before_mode == FCM_EXTRAPOLATE_CYCLIC && data->after_mode == FCM_EXTRAPOLATE_CYCLIC) {
return FCU_CYCLE_PERFECT;
}
if (ELEM(data->before_mode, FCM_EXTRAPOLATE_CYCLIC, FCM_EXTRAPOLATE_CYCLIC_OFFSET) &&
Cleanup: style
2018-11-01 07:31:49 +11:00
ELEM(data->after_mode, FCM_EXTRAPOLATE_CYCLIC, FCM_EXTRAPOLATE_CYCLIC_OFFSET))
{
Add an option to do keyframe insertion in a cycle-aware fashion. When enabled, inserting keyframes into F-Curves with simple cyclic extrapolation (the same conditions as required for cycle-aware auto handle smoothing to activate) will take the cycle into account: - Keyframes that are being inserted outside of the cycle bounds are remapped to be inside the cycle. Thus it is not necessary to be within the main iteration of the cycle when tweaking. This becomes especially useful in the final animation tweaking phase when the channel keys may be staggered for overlap, so the actual master period is different for different channels. - Modifying one of the end points of a cycle also changes the other end point when appropriate, to preserve smooth transition. This feature applies to both manual keyframe insertion using 'I', and auto-keyframing. Differential Revision: https://developer.blender.org/D3140
2018-10-14 13:04:34 +03:00
return FCU_CYCLE_OFFSET;
}
}
return FCU_CYCLE_NONE;
}
/* Checks if the F-Curve has a Cycles modifier with simple settings that warrant transition smoothing */
bool BKE_fcurve_is_cyclic(FCurve *fcu)
{
return BKE_fcurve_get_cycle_type(fcu) != FCU_CYCLE_NONE;
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
}
/* Shifts 'in' by the difference in coordinates between 'to' and 'from', using 'out' as the output buffer.
* When 'to' and 'from' are end points of the loop, this moves the 'in' point one loop cycle.
*/
static BezTriple *cycle_offset_triple(bool cycle, BezTriple *out, const BezTriple *in, const BezTriple *from, const BezTriple *to)
{
if (!cycle)
return NULL;
memcpy(out, in, sizeof(BezTriple));
float delta[3];
sub_v3_v3v3(delta, to->vec[1], from->vec[1]);
for (int i = 0; i < 3; i++)
add_v3_v3(out->vec[i], delta);
return out;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* This function recalculates the handles of an F-Curve
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
* If the BezTriples have been rearranged, sort them first before using this.
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void calchandles_fcurve(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
{
BezTriple *bezt, *prev, *next;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
int a = fcu->totvert;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* Error checking:
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - need at least two points
* - need bezier keys
* - only bezier-interpolation has handles (for now)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
if (ELEM(NULL, fcu, fcu->bezt) || (a < 2) /*|| ELEM(fcu->ipo, BEZT_IPO_CONST, BEZT_IPO_LIN)*/)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
return;
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
/* if the first modifier is Cycles, smooth the curve through the cycle */
Cleanup: style
2017-11-01 11:56:56 +11:00
BezTriple *first = &fcu->bezt[0], *last = &fcu->bezt[fcu->totvert - 1];
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
BezTriple tmp;
bool cycle = BKE_fcurve_is_cyclic(fcu) && BEZT_IS_AUTOH(first) && BEZT_IS_AUTOH(last);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 initial pointers */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
bezt = fcu->bezt;
Cleanup: style
2017-11-01 11:56:56 +11:00
prev = cycle_offset_triple(cycle, &tmp, &fcu->bezt[fcu->totvert - 2], last, first);
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
next = (bezt + 1);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* loop over all beztriples, adjusting handles */
while (a--) {
/* clamp timing of handles to be on either side of beztriple */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (bezt->vec[0][0] > bezt->vec[1][0]) bezt->vec[0][0] = bezt->vec[1][0];
if (bezt->vec[2][0] < bezt->vec[1][0]) bezt->vec[2][0] = bezt->vec[1][0];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* calculate auto-handles */
Implement a new automatic handle algorithm to produce smooth F-Curves. The legacy algorithm only considers two adjacent points when computing the bezier handles, which cannot produce satisfactory results. Animators are often forced to manually adjust all curves. The new approach instead solves a system of equations to trace a cubic spline with continuous second derivative through the whole segment of auto points, delimited at ends by keyframes with handles set by other requirements. This algorithm also adjusts Vector handles that face ordinary bezier keyframes to achieve zero acceleration at the Vector keyframe, instead of simply pointing it at the adjacent point. Original idea and implementation by Benoit Bolsee <benoit.bolsee@online.be>; code mostly rewritten to improve code clarity and extensibility. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2884
2017-11-01 21:34:30 +03:00
BKE_nurb_handle_calc(bezt, prev, next, true, fcu->auto_smoothing);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* for automatic ease in and out */
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
if (BEZT_IS_AUTOH(bezt) && !cycle) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 do this on first or last beztriple */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if ((a == 0) || (a == fcu->totvert - 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
/* set both handles to have same horizontal value as keyframe */
if (fcu->extend == FCURVE_EXTRAPOLATE_CONSTANT) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
bezt->vec[0][1] = bezt->vec[2][1] = bezt->vec[1][1];
Implement a new automatic handle algorithm to produce smooth F-Curves. The legacy algorithm only considers two adjacent points when computing the bezier handles, which cannot produce satisfactory results. Animators are often forced to manually adjust all curves. The new approach instead solves a system of equations to trace a cubic spline with continuous second derivative through the whole segment of auto points, delimited at ends by keyframes with handles set by other requirements. This algorithm also adjusts Vector handles that face ordinary bezier keyframes to achieve zero acceleration at the Vector keyframe, instead of simply pointing it at the adjacent point. Original idea and implementation by Benoit Bolsee <benoit.bolsee@online.be>; code mostly rewritten to improve code clarity and extensibility. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2884
2017-11-01 21:34:30 +03:00
/* remember that these keyframes are special, they don't need to be adjusted */
bezt->f5 = HD_AUTOTYPE_SPECIAL;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
}
}
Implement a new automatic handle algorithm to produce smooth F-Curves. The legacy algorithm only considers two adjacent points when computing the bezier handles, which cannot produce satisfactory results. Animators are often forced to manually adjust all curves. The new approach instead solves a system of equations to trace a cubic spline with continuous second derivative through the whole segment of auto points, delimited at ends by keyframes with handles set by other requirements. This algorithm also adjusts Vector handles that face ordinary bezier keyframes to achieve zero acceleration at the Vector keyframe, instead of simply pointing it at the adjacent point. Original idea and implementation by Benoit Bolsee <benoit.bolsee@online.be>; code mostly rewritten to improve code clarity and extensibility. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2884
2017-11-01 21:34:30 +03:00
/* avoid total smoothing failure on duplicate keyframes (can happen during grab) */
if (prev && prev->vec[1][0] >= bezt->vec[1][0]) {
prev->f5 = bezt->f5 = HD_AUTOTYPE_SPECIAL;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* advance pointers for next iteration */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
prev = bezt;
Make auto handle placement aware of cyclic extrapolation. Cyclic extrapolation is implemented as an f-curve modifier, so this technically violates abstraction separation and is something of a hack. However without such behavior achieving smooth looping with cyclic extrapolation is extremely cumbersome. The new behavior is applied when the first modifier is Cyclic extrapolation in Repeat or Repeat with Offset mode without using influence, repeat count or range restrictions. This change in behavior means that curve handles have to be updated when the modifier is added, removed or its options change. Due to the way code is structured, it seems it requires a helper link to the containing curve from the modifier object. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2783
2017-10-17 19:39:10 +03:00
if (a == 1) {
next = cycle_offset_triple(cycle, &tmp, &fcu->bezt[1], first, last);
}
else {
next++;
}
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
bezt++;
}
Implement a new automatic handle algorithm to produce smooth F-Curves. The legacy algorithm only considers two adjacent points when computing the bezier handles, which cannot produce satisfactory results. Animators are often forced to manually adjust all curves. The new approach instead solves a system of equations to trace a cubic spline with continuous second derivative through the whole segment of auto points, delimited at ends by keyframes with handles set by other requirements. This algorithm also adjusts Vector handles that face ordinary bezier keyframes to achieve zero acceleration at the Vector keyframe, instead of simply pointing it at the adjacent point. Original idea and implementation by Benoit Bolsee <benoit.bolsee@online.be>; code mostly rewritten to improve code clarity and extensibility. Reviewers: aligorith Differential Revision: https://developer.blender.org/D2884
2017-11-01 21:34:30 +03:00
/* if cyclic extrapolation and Auto Clamp has triggered, ensure it is symmetric */
if (cycle && (first->f5 != HD_AUTOTYPE_NORMAL || last->f5 != HD_AUTOTYPE_NORMAL)) {
first->vec[0][1] = first->vec[2][1] = first->vec[1][1];
last->vec[0][1] = last->vec[2][1] = last->vec[1][1];
first->f5 = last->f5 = HD_AUTOTYPE_SPECIAL;
}
/* do a second pass for auto handle: compute the handle to have 0 accelaration step */
if (fcu->auto_smoothing != FCURVE_SMOOTH_NONE) {
BKE_nurb_handle_smooth_fcurve(fcu->bezt, fcu->totvert, cycle);
}
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
fix for error setting vector handles to free when both vector handles were selected but not the mid-point. only one of the handles would be changed to the HD_FREE. effected curves and fcurves.
2013-10-01 08:18:43 +00:00
void testhandles_fcurve(FCurve *fcu, const bool use_handle)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
BezTriple *bezt;
Animato - Support for 'BuiltIn' and 'Relative' Keying Sets When inserting keyframes in the 3D-View (support will be extended to other editors in due course) using the IKEY hotkey, the menu which appears will now consist of 3 parts: * 'Active Keying Set' - this option allows you to use the user-defined KeyingSet which is active for the current scene (i.e. the one seen in the TimeLine/Outliner headers) * User defined Keying Sets - a list of all such available KeyingSets is included, and entries can be chosen from there * Built-In Keying Sets - see later... To achieve this, several changes needed to be made first: * Added support for 'relative' in addition to 'absolute' Keying Sets. Relative Keying Sets are Keying Sets which operate on data from the current context (i.e. a 'location' KeyingSet will add location keyframes for selected objects/bones/nodes as opposed to location keyframes for some particular object). The is a tentative 'templates' requirement system here, which still needs to be fully fleshed out. * Added support for builtin Keying Sets (i.e. 'Location', 'Rotation', 'Scaling', and 'LocRot' as a few initial demonstrations), which replaces the temporary Insert Keyframe operator for the 3D-View (IKEY). These are effectively relative Keying Set definitions which are included in Blender by default and stored in a list separate from user-defined ones. Volunteer help in defining a few more of these for other editors will be welcome soon. * Removed/replaced much of the crappy temporary Keyframing operator code, though a few tweaks could still be done.
2009-03-31 22:36:13 +00:00
unsigned int a;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 beztriples have handles (bpoints don't though) */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, fcu, fcu->bezt))
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
return;
fix for error setting vector handles to free when both vector handles were selected but not the mid-point. only one of the handles would be changed to the HD_FREE. effected curves and fcurves.
2013-10-01 08:18:43 +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
/* loop over beztriples */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (a = 0, bezt = fcu->bezt; a < fcu->totvert; a++, bezt++) {
fix for error setting vector handles to free when both vector handles were selected but not the mid-point. only one of the handles would be changed to the HD_FREE. effected curves and fcurves.
2013-10-01 08:18:43 +00:00
BKE_nurb_bezt_handle_test(bezt, use_handle);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 handles */
calchandles_fcurve(fcu);
}
/* This function sorts BezTriples so that they are arranged in chronological order,
* as tools working on F-Curves expect that the BezTriples are in order.
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void sort_time_fcurve(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
{
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
bool ok = true;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* keep adjusting order of beztriples until nothing moves (bubble-sort) */
while (ok) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
ok = 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* currently, will only be needed when there are beztriples */
if (fcu->bezt) {
BezTriple *bezt;
Animato - Support for 'BuiltIn' and 'Relative' Keying Sets When inserting keyframes in the 3D-View (support will be extended to other editors in due course) using the IKEY hotkey, the menu which appears will now consist of 3 parts: * 'Active Keying Set' - this option allows you to use the user-defined KeyingSet which is active for the current scene (i.e. the one seen in the TimeLine/Outliner headers) * User defined Keying Sets - a list of all such available KeyingSets is included, and entries can be chosen from there * Built-In Keying Sets - see later... To achieve this, several changes needed to be made first: * Added support for 'relative' in addition to 'absolute' Keying Sets. Relative Keying Sets are Keying Sets which operate on data from the current context (i.e. a 'location' KeyingSet will add location keyframes for selected objects/bones/nodes as opposed to location keyframes for some particular object). The is a tentative 'templates' requirement system here, which still needs to be fully fleshed out. * Added support for builtin Keying Sets (i.e. 'Location', 'Rotation', 'Scaling', and 'LocRot' as a few initial demonstrations), which replaces the temporary Insert Keyframe operator for the 3D-View (IKEY). These are effectively relative Keying Set definitions which are included in Blender by default and stored in a list separate from user-defined ones. Volunteer help in defining a few more of these for other editors will be welcome soon. * Removed/replaced much of the crappy temporary Keyframing operator code, though a few tweaks could still be done.
2009-03-31 22:36:13 +00:00
unsigned int a;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* loop over ALL points to adjust position in array and recalculate handles */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (a = 0, bezt = fcu->bezt; a < fcu->totvert; a++, bezt++) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 thee's a next beztriple which we could try to swap with current */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (a < (fcu->totvert - 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
/* swap if one is after the other (and indicate that order has changed) */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (bezt->vec[1][0] > (bezt + 1)->vec[1][0]) {
SWAP(BezTriple, *bezt, *(bezt + 1));
ok = 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
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* if either one of both of the points exceeds crosses over the keyframe time... */
if ( (bezt->vec[0][0] > bezt->vec[1][0]) && (bezt->vec[2][0] < bezt->vec[1][0]) ) {
/* swap handles if they have switched sides for some reason */
Cleanup: use swap math funcs
2015-07-01 16:02:30 +10:00
swap_v2_v2(bezt->vec[0], bezt->vec[2]);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 {
/* clamp handles */
Cleanup: use swap math funcs
2015-07-01 16:02:30 +10:00
CLAMP_MAX(bezt->vec[0][0], bezt->vec[1][0]);
CLAMP_MIN(bezt->vec[2][0], bezt->vec[1][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
}
}
}
}
}
}
/* This function tests if any BezTriples are out of order, thus requiring a sort */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
short test_time_fcurve(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
{
Animato - Support for 'BuiltIn' and 'Relative' Keying Sets When inserting keyframes in the 3D-View (support will be extended to other editors in due course) using the IKEY hotkey, the menu which appears will now consist of 3 parts: * 'Active Keying Set' - this option allows you to use the user-defined KeyingSet which is active for the current scene (i.e. the one seen in the TimeLine/Outliner headers) * User defined Keying Sets - a list of all such available KeyingSets is included, and entries can be chosen from there * Built-In Keying Sets - see later... To achieve this, several changes needed to be made first: * Added support for 'relative' in addition to 'absolute' Keying Sets. Relative Keying Sets are Keying Sets which operate on data from the current context (i.e. a 'location' KeyingSet will add location keyframes for selected objects/bones/nodes as opposed to location keyframes for some particular object). The is a tentative 'templates' requirement system here, which still needs to be fully fleshed out. * Added support for builtin Keying Sets (i.e. 'Location', 'Rotation', 'Scaling', and 'LocRot' as a few initial demonstrations), which replaces the temporary Insert Keyframe operator for the 3D-View (IKEY). These are effectively relative Keying Set definitions which are included in Blender by default and stored in a list separate from user-defined ones. Volunteer help in defining a few more of these for other editors will be welcome soon. * Removed/replaced much of the crappy temporary Keyframing operator code, though a few tweaks could still be done.
2009-03-31 22:36:13 +00:00
unsigned int a;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* sanity checks */
if (fcu == NULL)
return 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* currently, only need to test beztriples */
if (fcu->bezt) {
BezTriple *bezt;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* loop through all BezTriples, stopping when one exceeds the one after it */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (a = 0, bezt = fcu->bezt; a < (fcu->totvert - 1); a++, bezt++) {
if (bezt->vec[1][0] > (bezt + 1)->vec[1][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
return 1;
}
}
else if (fcu->fpt) {
FPoint *fpt;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* loop through all FPoints, stopping when one exceeds the one after it */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (a = 0, fpt = fcu->fpt; a < (fcu->totvert - 1); a++, fpt++) {
if (fpt->vec[0] > (fpt + 1)->vec[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
return 1;
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* none need any swapping */
return 0;
}
/* ***************************** Drivers ********************************* */
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* Driver Variables --------------------------- */
compile python driver expressions for faster re-evaluation. approx 15-25x speedup
2009-12-08 10:36:46 +00:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* TypeInfo for Driver Variables (dvti) */
typedef struct DriverVarTypeInfo {
/* evaluation callback */
float (*get_value)(ChannelDriver *driver, DriverVar *dvar);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* allocation of target slots */
Bugfix: Types mismatch (flags and targetFlags were ints, but dtar->flag is a short)
2013-02-28 10:27:04 +00:00
int num_targets; /* number of target slots required */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
const char *target_names[MAX_DRIVER_TARGETS]; /* UI names that should be given to the slots */
Bugfix: Types mismatch (flags and targetFlags were ints, but dtar->flag is a short)
2013-02-28 10:27:04 +00:00
short target_flags[MAX_DRIVER_TARGETS]; /* flags defining the requirements for each slot */
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
} DriverVarTypeInfo;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* Macro to begin definitions */
#define BEGIN_DVAR_TYPEDEF(type) \
{
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* Macro to end definitions */
#define END_DVAR_TYPEDEF \
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
}
Animato: Added base-code for converting the ugly old bitflag settings Only object layers have been done for now. The implementation of this should provide a good indicator for how this should be done. Unforunately, the code for animating layer visibility is not that straightforward, since scene->base->layer (not set) settings need to be synchronised with the object->layer (set by Animato) settings.
2009-01-29 09:40:49 +00:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* ......... */
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
added support for proxies as drivers back.
2010-02-23 17:56:45 +00:00
static ID *dtar_id_ensure_proxy_from(ID *id)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (id && GS(id->name) == ID_OB && ((Object *)id)->proxy_from)
added support for proxies as drivers back.
2010-02-23 17:56:45 +00:00
return (ID *)(((Object *)id)->proxy_from);
return id;
}
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
/* Helper function to obtain a value using RNA from the specified source (for evaluating drivers) */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static float dtar_get_prop_val(ChannelDriver *driver, DriverTarget *dtar)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
PointerRNA id_ptr, ptr;
PropertyRNA *prop;
Animato - Driver + ShapeKey bugfixes * ShapeKey conversions should now go to the correct places * Added fix for drivers to prevent crashes when no driver object is provided (Franky from BBB seems to have one such driver for some reason). * Temporarily disabled a check when evaluating drivers for whether the driver is tagged for evaluation. Drivers still need to be correctly tagged AND ordered by the Depsgraph to work correctly.
2009-01-28 00:50:56 +00:00
ID *id;
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
int index = -1;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
float value = 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
/* sanity check */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, driver, dtar))
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
return 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
id = dtar_id_ensure_proxy_from(dtar->id);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - Driver + ShapeKey bugfixes * ShapeKey conversions should now go to the correct places * Added fix for drivers to prevent crashes when no driver object is provided (Franky from BBB seems to have one such driver for some reason). * Temporarily disabled a check when evaluating drivers for whether the driver is tagged for evaluation. Drivers still need to be correctly tagged AND ordered by the Depsgraph to work correctly.
2009-01-28 00:50:56 +00:00
/* error check for missing pointer... */
if (id == NULL) {
Driver error warnings are now only printed to the console when Blender is run using the -d flag This prevents a stream of error messages flooding the console when working with particular rigs which may have a few broken controls. In general, riggers now have a better alternative by using the filtering tools in the Graph Editor.
2013-03-21 06:11:16 +00:00
if (G.debug & G_DEBUG) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "driver has an invalid target to use (path = %s)", dtar->rna_path);
Driver error warnings are now only printed to the console when Blender is run using the -d flag This prevents a stream of error messages flooding the console when working with particular rigs which may have a few broken controls. In general, riggers now have a better alternative by using the filtering tools in the Graph Editor.
2013-03-21 06:11:16 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - Driver + ShapeKey bugfixes * ShapeKey conversions should now go to the correct places * Added fix for drivers to prevent crashes when no driver object is provided (Franky from BBB seems to have one such driver for some reason). * Temporarily disabled a check when evaluating drivers for whether the driver is tagged for evaluation. Drivers still need to be correctly tagged AND ordered by the Depsgraph to work correctly.
2009-01-28 00:50:56 +00:00
driver->flag |= DRIVER_FLAG_INVALID;
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
dtar->flag |= DTAR_FLAG_INVALID;
Animato - Driver + ShapeKey bugfixes * ShapeKey conversions should now go to the correct places * Added fix for drivers to prevent crashes when no driver object is provided (Franky from BBB seems to have one such driver for some reason). * Temporarily disabled a check when evaluating drivers for whether the driver is tagged for evaluation. Drivers still need to be correctly tagged AND ordered by the Depsgraph to work correctly.
2009-01-28 00:50:56 +00:00
return 0.0f;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
added support for proxies as drivers back.
2010-02-23 17:56:45 +00:00
/* get RNA-pointer for the ID-block given in target */
RNA_id_pointer_create(id, &id_ptr);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* get property to read from, and get value as appropriate */
Bugfix [#34836] Crash when driver variable has path == 'data' Most of the places which relied on RNA_path_resolve() did so believing that if it returned true, that it had found a valid property, and that the returned pointer+property combination would be what the path referred to. However, it turns out that if the property at the end of the path turns out to be a "pointer" property (e.g. "data" for Object.data), this would automatically become the pointer part, while the prop part would be set to null. Hence, if a user accidentally (or otherwise) specifies a path for the single-property driver variable type like this, then Blender would crash. This commit introduces two convenience functions - RNA_path_resolve_property() and RNA_path_resolve_property_full() - which mirror/wrap the existing RNA_path_resolve() functions. The only difference though is that these include a check to ensure that what was found from resolving the path was in fact a property (they only return true iff this is the case), and make it explicitly clear in the name that this is what they will do so that there's no further confusion. It is possible to do without these wrapper functions by doing these checks inline, but the few cases that had been patched already were pretty hideous looking specimens. Using these just make it clearer and simpler for all. I've also beefed up the docs on these a bit, and changed these to using bools.
2013-04-22 13:22:07 +00:00
if (RNA_path_resolve_property_full(&id_ptr, dtar->rna_path, &ptr, &prop, &index)) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (RNA_property_array_check(prop)) {
drivers could reference invalid index values outside the bounds of the array.
2010-11-24 21:33:07 +00:00
/* array */
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
if ((index >= 0) && (index < RNA_property_array_length(&ptr, prop))) {
drivers could reference invalid index values outside the bounds of the array.
2010-11-24 21:33:07 +00:00
switch (RNA_property_type(prop)) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
case PROP_BOOLEAN:
value = (float)RNA_property_boolean_get_index(&ptr, prop, index);
break;
case PROP_INT:
value = (float)RNA_property_int_get_index(&ptr, prop, index);
break;
case PROP_FLOAT:
value = RNA_property_float_get_index(&ptr, prop, index);
break;
default:
break;
}
}
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
else {
/* out of bounds */
if (G.debug & G_DEBUG) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "Driver Evaluation Error: array index is out of bounds for %s -> %s (%d)",
id->name, dtar->rna_path, index);
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
driver->flag |= DRIVER_FLAG_INVALID;
dtar->flag |= DTAR_FLAG_INVALID;
return 0.0f;
}
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
}
else {
/* not an array */
switch (RNA_property_type(prop)) {
drivers could reference invalid index values outside the bounds of the array.
2010-11-24 21:33:07 +00:00
case PROP_BOOLEAN:
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
value = (float)RNA_property_boolean_get(&ptr, prop);
drivers could reference invalid index values outside the bounds of the array.
2010-11-24 21:33:07 +00:00
break;
case PROP_INT:
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
value = (float)RNA_property_int_get(&ptr, prop);
drivers could reference invalid index values outside the bounds of the array.
2010-11-24 21:33:07 +00:00
break;
case PROP_FLOAT:
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
value = RNA_property_float_get(&ptr, prop);
break;
case PROP_ENUM:
value = (float)RNA_property_enum_get(&ptr, prop);
drivers could reference invalid index values outside the bounds of the array.
2010-11-24 21:33:07 +00:00
break;
default:
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
}
}
Driver Editing Tweaks: * Updating dependencies for drivers now clears the disabled status of the relevant Driver FCurve too * Changing the type of ID-block used for Driver Targets and Keying Set Paths will now clear the pointer to the ID-block if it is of the wrong type.
2009-11-13 01:04:01 +00:00
else {
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
/* path couldn't be resolved */
Driver error warnings are now only printed to the console when Blender is run using the -d flag This prevents a stream of error messages flooding the console when working with particular rigs which may have a few broken controls. In general, riggers now have a better alternative by using the filtering tools in the Graph Editor.
2013-03-21 06:11:16 +00:00
if (G.debug & G_DEBUG) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "Driver Evaluation Error: cannot resolve target for %s -> %s", id->name, dtar->rna_path);
Driver error warnings are now only printed to the console when Blender is run using the -d flag This prevents a stream of error messages flooding the console when working with particular rigs which may have a few broken controls. In general, riggers now have a better alternative by using the filtering tools in the Graph Editor.
2013-03-21 06:11:16 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Driver Editing Tweaks: * Updating dependencies for drivers now clears the disabled status of the relevant Driver FCurve too * Changing the type of ID-block used for Driver Targets and Keying Set Paths will now clear the pointer to the ID-block if it is of the wrong type.
2009-11-13 01:04:01 +00:00
driver->flag |= DRIVER_FLAG_INVALID;
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
dtar->flag |= DTAR_FLAG_INVALID;
Driver Editing Tweaks: * Updating dependencies for drivers now clears the disabled status of the relevant Driver FCurve too * Changing the type of ID-block used for Driver Targets and Keying Set Paths will now clear the pointer to the ID-block if it is of the wrong type.
2009-11-13 01:04:01 +00:00
return 0.0f;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
/* if we're still here, we should be ok... */
dtar->flag &= ~DTAR_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
return value;
}
PyDriver support for all RNA property types Support for driver variables that don't resolve to numbers, eg: objects, bones, curves... etc. Without this, Python expressions to access this data needed to use an absolute path from `bpy.data`, however this is inconvenient, breaks easily (based on naming) and wouldn't set the dependencies correctly.
2016-04-05 07:02:43 +10:00
/**
* Same as 'dtar_get_prop_val'. but get the RNA property.
*/
bool driver_get_variable_property(
ChannelDriver *driver, DriverTarget *dtar,
PointerRNA *r_ptr, PropertyRNA **r_prop, int *r_index)
{
PointerRNA id_ptr;
PointerRNA ptr;
PropertyRNA *prop;
ID *id;
int index = -1;
/* sanity check */
if (ELEM(NULL, driver, dtar))
return false;
id = dtar_id_ensure_proxy_from(dtar->id);
/* error check for missing pointer... */
if (id == NULL) {
if (G.debug & G_DEBUG) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "driver has an invalid target to use (path = %s)", dtar->rna_path);
PyDriver support for all RNA property types Support for driver variables that don't resolve to numbers, eg: objects, bones, curves... etc. Without this, Python expressions to access this data needed to use an absolute path from `bpy.data`, however this is inconvenient, breaks easily (based on naming) and wouldn't set the dependencies correctly.
2016-04-05 07:02:43 +10:00
}
driver->flag |= DRIVER_FLAG_INVALID;
dtar->flag |= DTAR_FLAG_INVALID;
return false;
}
/* get RNA-pointer for the ID-block given in target */
RNA_id_pointer_create(id, &id_ptr);
/* get property to read from, and get value as appropriate */
if (dtar->rna_path == NULL || dtar->rna_path[0] == '\0') {
ptr = PointerRNA_NULL;
prop = NULL; /* ok */
}
else if (RNA_path_resolve_property_full(&id_ptr, dtar->rna_path, &ptr, &prop, &index)) {
/* ok */
}
else {
/* path couldn't be resolved */
if (G.debug & G_DEBUG) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "Driver Evaluation Error: cannot resolve target for %s -> %s", id->name, dtar->rna_path);
PyDriver support for all RNA property types Support for driver variables that don't resolve to numbers, eg: objects, bones, curves... etc. Without this, Python expressions to access this data needed to use an absolute path from `bpy.data`, however this is inconvenient, breaks easily (based on naming) and wouldn't set the dependencies correctly.
2016-04-05 07:02:43 +10:00
}
ptr = PointerRNA_NULL;
*r_prop = NULL;
*r_index = -1;
driver->flag |= DRIVER_FLAG_INVALID;
dtar->flag |= DTAR_FLAG_INVALID;
return false;
}
*r_ptr = ptr;
*r_prop = prop;
*r_index = index;
/* if we're still here, we should be ok... */
dtar->flag &= ~DTAR_FLAG_INVALID;
return true;
}
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
static short driver_check_valid_targets(ChannelDriver *driver, DriverVar *dvar)
{
short valid_targets = 0;
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_USED_LOOPER_BEGIN(dvar)
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
{
Object *ob = (Object *)dtar_id_ensure_proxy_from(dtar->id);
/* check if this target has valid data */
if ((ob == NULL) || (GS(ob->id.name) != ID_OB)) {
/* invalid target, so will not have enough targets */
driver->flag |= DRIVER_FLAG_INVALID;
dtar->flag |= DTAR_FLAG_INVALID;
}
else {
/* target seems to be OK now... */
dtar->flag &= ~DTAR_FLAG_INVALID;
valid_targets++;
}
}
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_LOOPER_END;
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
return valid_targets;
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* ......... */
/* evaluate 'single prop' driver variable */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static float dvar_eval_singleProp(ChannelDriver *driver, DriverVar *dvar)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
/* just evaluate the first target slot */
return dtar_get_prop_val(driver, &dvar->targets[0]);
}
/* evaluate 'rotation difference' driver variable */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static float dvar_eval_rotDiff(ChannelDriver *driver, DriverVar *dvar)
Drivers - Rotational Difference Restored the code to get this working. I haven't tested this to verify it, but it 'should' work... Also, deleted old gpencil.c file in editors, since it was causing compiling errors.
2009-04-20 10:45:25 +00:00
{
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
short valid_targets = driver_check_valid_targets(driver, dvar);
/* make sure we have enough valid targets to use - all or nothing for now... */
if (driver_check_valid_targets(driver, dvar) != 2) {
if (G.debug & G_DEBUG) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_WARN(&LOG, "RotDiff DVar: not enough valid targets (n = %d) (a = %p, b = %p)",
valid_targets, dvar->targets[0].id, dvar->targets[1].id);
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
return 0.0f;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
float (*mat[2])[4];
/* NOTE: for now, these are all just worldspace */
for (int i = 0; i < 2; i++) {
/* get pointer to loc values to store in */
DriverTarget *dtar = &dvar->targets[i];
Object *ob = (Object *)dtar_id_ensure_proxy_from(dtar->id);
bPoseChannel *pchan;
/* after the checks above, the targets should be valid here... */
BLI_assert((ob != NULL) && (GS(ob->id.name) == ID_OB));
/* try to get posechannel */
pchan = BKE_pose_channel_find_name(ob->pose, dtar->pchan_name);
/* check if object or bone */
if (pchan) {
/* bone */
mat[i] = pchan->pose_mat;
}
else {
/* object */
mat[i] = ob->obmat;
}
Fix T37667: rotational difference driver target marked invalid even though valid.
2013-12-01 15:05:03 +01:00
}
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
float q1[4], q2[4], quat[4], angle;
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* use the final posed locations */
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
mat4_to_quat(q1, mat[0]);
mat4_to_quat(q2, mat[1]);
BLI_math: add invert_qt_normalized When the quat is known to be unit length, so we can avoid scaling (just conjugate_qt which asserts on non unit quats).
2015-10-24 03:51:00 +11:00
invert_qt_normalized(q1);
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
mul_qt_qtqt(quat, q1, q2);
angle = 2.0f * (saacos(quat[0]));
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
angle = ABS(angle);
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
blenkernel: floats were being implicitly promoted to doubles, adjust to use floats.
2011-03-28 04:22:50 +00:00
return (angle > (float)M_PI) ? (float)((2.0f * (float)M_PI) - angle) : (float)(angle);
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
/* evaluate 'location difference' driver variable */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* TODO: this needs to take into account space conversions... */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static float dvar_eval_locDiff(ChannelDriver *driver, DriverVar *dvar)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
float loc1[3] = {0.0f, 0.0f, 0.0f};
float loc2[3] = {0.0f, 0.0f, 0.0f};
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
short valid_targets = driver_check_valid_targets(driver, dvar);
Bugfix: Invalid target tagging for "Distance" driver variable type only highlighted the first target if/when both targets were empty.
2013-02-28 10:50:13 +00:00
/* make sure we have enough valid targets to use - all or nothing for now... */
if (valid_targets < dvar->num_targets) {
if (G.debug & G_DEBUG) {
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_WARN(&LOG, "LocDiff DVar: not enough valid targets (n = %d) (a = %p, b = %p)",
valid_targets, dvar->targets[0].id, dvar->targets[1].id);
Bugfix: Invalid target tagging for "Distance" driver variable type only highlighted the first target if/when both targets were empty.
2013-02-28 10:50:13 +00:00
}
return 0.0f;
}
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
Bugfix: Invalid target tagging for "Distance" driver variable type only highlighted the first target if/when both targets were empty.
2013-02-28 10:50:13 +00:00
/* SECOND PASS: get two location values */
/* NOTE: for now, these are all just worldspace */
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_USED_LOOPER_BEGIN(dvar)
Bugfix: Invalid target tagging for "Distance" driver variable type only highlighted the first target if/when both targets were empty.
2013-02-28 10:50:13 +00:00
{
/* get pointer to loc values to store in */
Object *ob = (Object *)dtar_id_ensure_proxy_from(dtar->id);
bPoseChannel *pchan;
float tmp_loc[3];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Invalid target tagging for "Distance" driver variable type only highlighted the first target if/when both targets were empty.
2013-02-28 10:50:13 +00:00
/* after the checks above, the targets should be valid here... */
correct assert for driver evaluation, also add asserts for listbase functions when the list is NULL, and use noreturn attribute for jpeg_error.
2013-05-12 05:54:33 +00:00
BLI_assert((ob != NULL) && (GS(ob->id.name) == ID_OB));
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* try to get posechannel */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
pchan = BKE_pose_channel_find_name(ob->pose, dtar->pchan_name);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* check if object or bone */
if (pchan) {
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* bone */
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
if (dtar->flag & DTAR_FLAG_LOCALSPACE) {
if (dtar->flag & DTAR_FLAG_LOCAL_CONSTS) {
float mat[4][4];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
/* extract transform just like how the constraints do it! */
copy_m4_m4(mat, pchan->pose_mat);
Fix T43204: Shrinkwrap constraint, project mode: Space ignored in bone case. Own fault in rBb154aa8c060a60d to fix T42447... Reverted that commit, and added kind of not-so-nice hack instead. Note root of the issue comes from the special case we are doing here re 'Local' space of parent-less objects. In that case, local space should be the same as world one, but instead we apply the object rotation to it... This is inconsistent with all other cases and could very well lead to other issues as T42447, but afraid fixing that properly would be rather hairy - not to mention it would likely break all existing riggings etc. :( Should be safe for a 2.73a, shall we need it.
2015-01-11 14:59:11 +01:00
BKE_constraint_mat_convertspace(ob, pchan, mat, CONSTRAINT_SPACE_POSE, CONSTRAINT_SPACE_LOCAL, false);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
/* ... and from that, we get our transform */
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(tmp_loc, mat[3]);
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
}
else {
/* transform space (use transform values directly) */
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(tmp_loc, pchan->loc);
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
}
}
else {
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* convert to worldspace */
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(tmp_loc, pchan->pose_head);
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
mul_m4_v3(ob->obmat, tmp_loc);
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
else {
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* object */
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
if (dtar->flag & DTAR_FLAG_LOCALSPACE) {
if (dtar->flag & DTAR_FLAG_LOCAL_CONSTS) {
style cleanup
2012-07-07 22:51:57 +00:00
/* XXX: this should practically be the same as transform space... */
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
float mat[4][4];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
/* extract transform just like how the constraints do it! */
copy_m4_m4(mat, ob->obmat);
Fix T43204: Shrinkwrap constraint, project mode: Space ignored in bone case. Own fault in rBb154aa8c060a60d to fix T42447... Reverted that commit, and added kind of not-so-nice hack instead. Note root of the issue comes from the special case we are doing here re 'Local' space of parent-less objects. In that case, local space should be the same as world one, but instead we apply the object rotation to it... This is inconsistent with all other cases and could very well lead to other issues as T42447, but afraid fixing that properly would be rather hairy - not to mention it would likely break all existing riggings etc. :( Should be safe for a 2.73a, shall we need it.
2015-01-11 14:59:11 +01:00
BKE_constraint_mat_convertspace(ob, NULL, mat, CONSTRAINT_SPACE_WORLD, CONSTRAINT_SPACE_LOCAL, false);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
/* ... and from that, we get our transform */
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(tmp_loc, mat[3]);
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
}
else {
/* transform space (use transform values directly) */
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(tmp_loc, ob->loc);
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
}
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
}
else {
Bugfix: Distance DVar doesn't work with new Local Space Fixed references in UI to the old property, and adapted the backend code to work for the new options too.
2011-06-14 11:01:36 +00:00
/* worldspace */
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(tmp_loc, ob->obmat[3]);
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* copy the location to the right place */
if (tarIndex) {
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(loc2, tmp_loc);
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
else {
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(loc1, tmp_loc);
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
}
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_LOOPER_END;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* if we're still here, there should now be two targets to use,
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
* so just take the length of the vector between these points
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
*/
return len_v3v3(loc1, loc2);
}
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* evaluate 'transform channel' driver variable */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static float dvar_eval_transChan(ChannelDriver *driver, DriverVar *dvar)
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
DriverTarget *dtar = &dvar->targets[0];
Object *ob = (Object *)dtar_id_ensure_proxy_from(dtar->id);
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
bPoseChannel *pchan;
float mat[4][4];
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
float oldEul[3] = {0.0f, 0.0f, 0.0f};
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
bool use_eulers = false;
short rot_order = ROT_MODE_EUL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* check if this target has valid data */
added support for proxies as drivers back.
2010-02-23 17:56:45 +00:00
if ((ob == NULL) || (GS(ob->id.name) != ID_OB)) {
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* invalid target, so will not have enough targets */
driver->flag |= DRIVER_FLAG_INVALID;
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
dtar->flag |= DTAR_FLAG_INVALID;
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
return 0.0f;
}
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
else {
/* target should be valid now */
dtar->flag &= ~DTAR_FLAG_INVALID;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* try to get posechannel */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
pchan = BKE_pose_channel_find_name(ob->pose, dtar->pchan_name);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* check if object or bone, and get transform matrix accordingly
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - "useEulers" code is used to prevent the problems associated with non-uniqueness
* of euler decomposition from matrices [#20870]
* - localspace is for [#21384], where parent results are not wanted
* but local-consts is for all the common "corrective-shapes-for-limbs" situations
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
*/
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
if (pchan) {
/* bone */
Bugfix #20870: Local rotation drivers behave weird Use euler rotations for local rotation drivers if the object/bone uses euler rotations. Otherwise, fall back to matrix-based conversions again.
2010-01-30 21:21:36 +00:00
if (pchan->rotmode > 0) {
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(oldEul, pchan->eul);
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
rot_order = pchan->rotmode;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
use_eulers = true;
Bugfix #20870: Local rotation drivers behave weird Use euler rotations for local rotation drivers if the object/bone uses euler rotations. Otherwise, fall back to matrix-based conversions again.
2010-01-30 21:21:36 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix #21384: Bone Driven Shapekeys Child Evaluation Problem Transform channel drivers for bones in 'localspace' was using the wrong matrix when getting the transforms. I had been assuming that pchan->chan_mat always contained only the matrix-ised transform values stored in the pchan (which is true while constraints are being evaluated, but not afterwards). Changes: - Added a new function to calculate this matrix instead of directly writing it on the pchan->chan_matrix field. - Also, made the normalisation of the quaternion values during this process be done on a temp var instead of on the stored value. This was a constant source of confusion in the past, so let's see if we can do without it now :) Unrelated to this commit, I've also fixed a compiler warning with previous commit that I missed (missing include).
2010-03-01 05:19:07 +00:00
if (dtar->flag & DTAR_FLAG_LOCALSPACE) {
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
if (dtar->flag & DTAR_FLAG_LOCAL_CONSTS) {
/* just like how the constraints do it! */
copy_m4_m4(mat, pchan->pose_mat);
Fix T43204: Shrinkwrap constraint, project mode: Space ignored in bone case. Own fault in rBb154aa8c060a60d to fix T42447... Reverted that commit, and added kind of not-so-nice hack instead. Note root of the issue comes from the special case we are doing here re 'Local' space of parent-less objects. In that case, local space should be the same as world one, but instead we apply the object rotation to it... This is inconsistent with all other cases and could very well lead to other issues as T42447, but afraid fixing that properly would be rather hairy - not to mention it would likely break all existing riggings etc. :( Should be safe for a 2.73a, shall we need it.
2015-01-11 14:59:11 +01:00
BKE_constraint_mat_convertspace(ob, pchan, mat, CONSTRAINT_SPACE_POSE, CONSTRAINT_SPACE_LOCAL, false);
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
}
else {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* specially calculate local matrix, since chan_mat is not valid
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
* since it stores delta transform of pose_mat so that deforms work
* so it cannot be used here for "transform" space
*/
code cleanup: naming - pose/armature/image also use ..._find_name(..., name) rather then ..._find_named(..., name) --- both were used.
2012-05-05 16:03:57 +00:00
BKE_pchan_to_mat4(pchan, mat);
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
}
Bugfix #21384: Bone Driven Shapekeys Child Evaluation Problem Transform channel drivers for bones in 'localspace' was using the wrong matrix when getting the transforms. I had been assuming that pchan->chan_mat always contained only the matrix-ised transform values stored in the pchan (which is true while constraints are being evaluated, but not afterwards). Changes: - Added a new function to calculate this matrix instead of directly writing it on the pchan->chan_matrix field. - Also, made the normalisation of the quaternion values during this process be done on a temp var instead of on the stored value. This was a constant source of confusion in the past, so let's see if we can do without it now :) Unrelated to this commit, I've also fixed a compiler warning with previous commit that I missed (missing include).
2010-03-01 05:19:07 +00:00
}
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
else {
/* worldspace matrix */
BLI_math rename functions: - mult_m4_m4m4 -> mul_m4_m4m4 - mult_m3_m3m4 -> mul_m3_m3m4 these temporary names were used to avoid problems when argument order was switched.
2013-05-26 18:36:25 +00:00
mul_m4_m4m4(mat, ob->obmat, pchan->pose_mat);
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
}
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
}
else {
/* object */
Bugfix #20870: Local rotation drivers behave weird Use euler rotations for local rotation drivers if the object/bone uses euler rotations. Otherwise, fall back to matrix-based conversions again.
2010-01-30 21:21:36 +00:00
if (ob->rotmode > 0) {
replace VECCOPY and QUATCOPY with inline funcs.
2011-10-28 12:40:15 +00:00
copy_v3_v3(oldEul, ob->rot);
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
rot_order = ob->rotmode;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
use_eulers = true;
Bugfix #20870: Local rotation drivers behave weird Use euler rotations for local rotation drivers if the object/bone uses euler rotations. Otherwise, fall back to matrix-based conversions again.
2010-01-30 21:21:36 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
if (dtar->flag & DTAR_FLAG_LOCALSPACE) {
if (dtar->flag & DTAR_FLAG_LOCAL_CONSTS) {
/* just like how the constraints do it! */
copy_m4_m4(mat, ob->obmat);
Fix T43204: Shrinkwrap constraint, project mode: Space ignored in bone case. Own fault in rBb154aa8c060a60d to fix T42447... Reverted that commit, and added kind of not-so-nice hack instead. Note root of the issue comes from the special case we are doing here re 'Local' space of parent-less objects. In that case, local space should be the same as world one, but instead we apply the object rotation to it... This is inconsistent with all other cases and could very well lead to other issues as T42447, but afraid fixing that properly would be rather hairy - not to mention it would likely break all existing riggings etc. :( Should be safe for a 2.73a, shall we need it.
2015-01-11 14:59:11 +01:00
BKE_constraint_mat_convertspace(ob, NULL, mat, CONSTRAINT_SPACE_WORLD, CONSTRAINT_SPACE_LOCAL, false);
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
}
else {
/* transforms to matrix */
code cleanup: function naming, use BKE_*type* prefix.
2012-05-05 14:03:12 +00:00
BKE_object_to_mat4(ob, mat);
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
}
}
else {
/* worldspace matrix - just the good-old one */
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
copy_m4_m4(mat, ob->obmat);
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
}
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
/* check which transform */
if (dtar->transChan >= MAX_DTAR_TRANSCHAN_TYPES) {
/* not valid channel */
return 0.0f;
}
else if (dtar->transChan >= DTAR_TRANSCHAN_SCALEX) {
FCurve: only calculate single axis length Was calculating all 3
2018-03-02 12:43:41 +11:00
/* Extract scale, and choose the right axis,
* inline 'mat4_to_size'. */
return len_v3(mat[dtar->transChan - DTAR_TRANSCHAN_SCALEX]);
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
}
else if (dtar->transChan >= DTAR_TRANSCHAN_ROTX) {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* extract rotation as eulers (if needed)
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - definitely if rotation order isn't eulers already
* - if eulers, then we have 2 options:
* a) decompose transform matrix as required, then try to make eulers from
* there compatible with original values
* b) [NOT USED] directly use the original values (no decomposition)
* - only an option for "transform space", if quality is really bad with a)
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
*/
float eul[3];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
mat4_to_eulO(eul, rot_order, mat);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
if (use_eulers) {
Transformation Channel Driver Variables - "Proper Localspace" By popular demand, the "Transformation Channel" driver variable type now has a "local space" transform space option which uses the same magic that constraints use for defining local-space. This is what many bug reporters and feature requesters have moaned about for a while now, so after reviewing several of the bug reports which lead to the current situation, here is what has been much-wanted for so long! In order to implement this, I've: - renamed the old "Local Space" option here to "Transformation Space", in order to prevent old rigs breaking. This has also been kept, as it is useful for #21384 (though perhaps with this new option it isn't needed anymore) - reviewed my fix for #20870 (IIRC, a Durian-era bug), which related to the non-uniqueness of matrix->euler decomposition
2011-06-13 13:54:21 +00:00
compatible_eul(eul, oldEul);
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
return eul[dtar->transChan - DTAR_TRANSCHAN_ROTX];
}
else {
/* extract location and choose right axis */
return mat[3][dtar->transChan];
}
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* ......... */
/* Table of Driver Varaiable Type Info Data */
fix for warnings from Sparse static source code checker, mostly BKE/BLI and python functions. - use NULL rather then 0 where possible (makes code & function calls more readable IMHO). - set static variables and functions (exposed some unused vars/funcs). - use func(void) rather then func() for definitions.
2011-02-13 10:52:18 +00:00
static DriverVarTypeInfo dvar_types[MAX_DVAR_TYPES] = {
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
BEGIN_DVAR_TYPEDEF(DVAR_TYPE_SINGLE_PROP)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar_eval_singleProp, /* eval callback */
1, /* number of targets used */
{"Property"}, /* UI names for targets */
{0} /* flags */
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
END_DVAR_TYPEDEF,
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
BEGIN_DVAR_TYPEDEF(DVAR_TYPE_ROT_DIFF)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar_eval_rotDiff, /* eval callback */
2, /* number of targets used */
Add support for Objects in Drive variable `Rotational Difference` Thus it is according to the Manual https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
2017-03-11 10:43:23 -03:00
{"Object/Bone 1", "Object/Bone 2"}, /* UI names for targets */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
{DTAR_FLAG_STRUCT_REF | DTAR_FLAG_ID_OB_ONLY, DTAR_FLAG_STRUCT_REF | DTAR_FLAG_ID_OB_ONLY} /* flags */
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
END_DVAR_TYPEDEF,
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
BEGIN_DVAR_TYPEDEF(DVAR_TYPE_LOC_DIFF)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar_eval_locDiff, /* eval callback */
2, /* number of targets used */
{"Object/Bone 1", "Object/Bone 2"}, /* UI names for targets */
{DTAR_FLAG_STRUCT_REF | DTAR_FLAG_ID_OB_ONLY, DTAR_FLAG_STRUCT_REF | DTAR_FLAG_ID_OB_ONLY} /* flags */
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
END_DVAR_TYPEDEF,
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
BEGIN_DVAR_TYPEDEF(DVAR_TYPE_TRANSFORM_CHAN)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar_eval_transChan, /* eval callback */
1, /* number of targets used */
{"Object/Bone"}, /* UI names for targets */
{DTAR_FLAG_STRUCT_REF | DTAR_FLAG_ID_OB_ONLY} /* flags */
More Driver Fixes: * Fixed Driver version-patching code to work correctly again with the new system. * Fix for bug #20484, by adding a new driver variable type ('Transform Channel') which makes it easier to use object/bone transforms as in the past. The main differences with using this (compared with the 'Single Prop' type) are that this allows for 'final' transforms to get used instead (i.e. constraints are also taken into account), and also that this variable type can only be used for transforms (more limited scope -> less flexibility -> point-n-click goodies can follow). Mancandy now loads correctly again. * Added toggle for local vs worldspace transforms when working with Rot/Loc Diff variable types, and also for the newly added Transform Channel * Removed some dead code from sequencer...
2010-01-05 11:59:12 +00:00
END_DVAR_TYPEDEF,
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
};
/* Get driver variable typeinfo */
Cleanup: use const for typeinfo
2015-03-30 21:17:07 +11:00
static const DriverVarTypeInfo *get_dvar_typeinfo(int type)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
/* check if valid type */
if ((type >= 0) && (type < MAX_DVAR_TYPES))
return &dvar_types[type];
else
return NULL;
}
/* Driver API --------------------------------- */
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
/* Perform actual freeing driver variable and remove it from the given list */
void driver_free_variable(ListBase *variables, DriverVar *dvar)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
/* sanity checks */
if (dvar == NULL)
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* free target vars
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - need to go over all of them, not just up to the ones that are used
* currently, since there may be some lingering RNA paths from
* previous users needing freeing
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
*/
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_LOOPER_BEGIN(dvar)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
/* free RNA path if applicable */
if (dtar->rna_path)
MEM_freeN(dtar->rna_path);
}
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_LOOPER_END;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* remove the variable from the driver */
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
BLI_freelinkN(variables, dvar);
}
fix for own but in recent driver optimization [#20580] Driver Crasher rev [25763] recalculate names when needed
2010-01-06 22:42:13 +00:00
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
/* Free the driver variable and do extra updates */
void driver_free_variable_ex(ChannelDriver *driver, DriverVar *dvar)
{
/* remove and free the driver variable */
driver_free_variable(&driver->variables, dvar);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
fix for own but in recent driver optimization [#20580] Driver Crasher rev [25763] recalculate names when needed
2010-01-06 22:42:13 +00:00
/* since driver variables are cached, the expression needs re-compiling too */
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
BKE_driver_invalidate_expression(driver, false, true);
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
/* Copy driver variables from src_vars list to dst_vars list */
void driver_variables_copy(ListBase *dst_vars, const ListBase *src_vars)
{
BLI_assert(BLI_listbase_is_empty(dst_vars));
BLI_duplicatelist(dst_vars, src_vars);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
for (DriverVar *dvar = dst_vars->first; dvar; dvar = dvar->next) {
/* need to go over all targets so that we don't leave any dangling paths */
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_LOOPER_BEGIN(dvar)
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
{
/* make a copy of target's rna path if available */
if (dtar->rna_path)
dtar->rna_path = MEM_dupallocN(dtar->rna_path);
}
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_LOOPER_END;
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
}
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* Change the type of driver variable */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
void driver_change_variable_type(DriverVar *dvar, int type)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
Cleanup: use const for typeinfo
2015-03-30 21:17:07 +11:00
const DriverVarTypeInfo *dvti = get_dvar_typeinfo(type);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* sanity check */
if (ELEM(NULL, dvar, dvti))
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* set the new settings */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar->type = type;
dvar->num_targets = dvti->num_targets;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* make changes to the targets based on the defines for these types
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
* NOTE: only need to make sure the ones we're using here are valid...
*/
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_USED_LOOPER_BEGIN(dvar)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
Bugfix: Types mismatch (flags and targetFlags were ints, but dtar->flag is a short)
2013-02-28 10:27:04 +00:00
short flags = dvti->target_flags[tarIndex];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* store the flags */
dtar->flag = flags;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Invalid Driver Targets are now indicated appropriately (using Red Backgrounds) in the UI This is the second part of the fixes for [#32492], making it easier to identify which part of a driver (i.e. which of its targets) is causing problems A number of additional/related changes needed to be made: * Red-alert status for layouts is now propagated down to child layouts when they are created. This is needed as otherwise some of the templates used in the Graph Editor driver settings won't actually get the red-alert status flushed down to them. Also, note that this status needs to be set before any widgets are added to the layout, or else the settings aren't applied when the relevant widgets get created. * "Single Property" RNA-Paths resulting in out of bounds array access will now trigger an error status and appropriate warnings TODO: * The error tagging doesn't get applied immediately after variables are created, or their types changed * There was also some other weirdness involved when a higher-value flag (1<<10) was used for this setting, which needs further attention
2013-02-28 07:13:33 +00:00
/* object ID types only, or idtype not yet initialized */
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
if ((flags & DTAR_FLAG_ID_OB_ONLY) || (dtar->idtype == 0))
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dtar->idtype = ID_OB;
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
Cleanup: name macros w/ matching BEGIN/END
2018-11-30 15:08:47 +11:00
DRIVER_TARGETS_LOOPER_END;
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
/* Validate driver name (after being renamed) */
void driver_variable_name_validate(DriverVar *dvar)
{
/* Special character blacklist */
const char special_char_blacklist[] = {
Fix dodgy indentation
2016-03-24 15:20:56 +13:00
'~', '`', '!', '@', '#', '$', '%', '^', '&', '*', '+', '=', '-',
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
'/', '\\', '?', ':', ';', '<', '>', '{', '}', '[', ']', '|',
Cleanup: trailing commas Needed for clan-format not to wrap onto one line.
2019-02-03 14:01:45 +11:00
' ', '.', '\t', '\n', '\r',
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
};
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
/* sanity checks */
if (dvar == NULL)
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
/* clear all invalid-name flags */
dvar->flag &= ~DVAR_ALL_INVALID_FLAGS;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Driver Variable Name Validation: Added missing check for zero-length (i.e. "blank") names
2016-03-26 18:01:02 +13:00
/* 0) Zero-length identifiers are not allowed */
if (dvar->name[0] == '\0') {
dvar->flag |= DVAR_FLAG_INVALID_EMPTY;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
/* 1) Must start with a letter */
/* XXX: We assume that valid unicode letters in other languages are ok too, hence the blacklisting */
Cleanup: redundant ELEM use
2017-11-21 16:14:31 +11:00
if (IN_RANGE_INCL(dvar->name[0], '0', '9')) {
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
dvar->flag |= DVAR_FLAG_INVALID_START_NUM;
}
else if (dvar->name[0] == '_') {
/* NOTE: We don't allow names to start with underscores (i.e. it helps when ruling out security risks) */
dvar->flag |= DVAR_FLAG_INVALID_START_CHAR;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
/* 2) Must not contain invalid stuff in the middle of the string */
if (strchr(dvar->name, ' ')) {
dvar->flag |= DVAR_FLAG_INVALID_HAS_SPACE;
}
if (strchr(dvar->name, '.')) {
dvar->flag |= DVAR_FLAG_INVALID_HAS_DOT;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
/* 3) Check for special characters - Either at start, or in the middle */
for (int i = 0; i < sizeof(special_char_blacklist); i++) {
char *match = strchr(dvar->name, special_char_blacklist[i]);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
if (match == dvar->name)
dvar->flag |= DVAR_FLAG_INVALID_START_CHAR;
else if (match != NULL)
dvar->flag |= DVAR_FLAG_INVALID_HAS_SPECIAL;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
/* 4) Check if the name is a reserved keyword
* NOTE: These won't confuse Python, but it will be impossible to use the variable
* in an expression without Python misinterpreting what these are for
*/
Generic check for string being a Py keyword Driver code used incomplete list of Py keywords
2016-04-01 09:43:11 +11:00
#ifdef WITH_PYTHON
if (BPY_string_is_keyword(dvar->name)) {
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
dvar->flag |= DVAR_FLAG_INVALID_PY_KEYWORD;
}
Generic check for string being a Py keyword Driver code used incomplete list of Py keywords
2016-04-01 09:43:11 +11:00
#endif
Drivers UI: Added name validation/linting for Driver Variables When attempting to change a driver variable name to an "invalid" name, an indicator will now be shown beside the offending variable name. Clicking on this icon will show a popup which provides more information about why the variable name cannot be used. Reasons that it knows about are: 1) Starts with number 2) Has a dot 3) Has a space 4) Starts with or contains a special character 5) Starts with an underscore (Python does allow this, but it's bad practice, and makes checking security of drivers harder) 6) Is a reserved Python keyword
2016-03-24 15:15:04 +13:00
/* If any these conditions match, the name is invalid */
if (dvar->flag & DVAR_ALL_INVALID_FLAGS)
dvar->flag |= DVAR_FLAG_INVALID_NAME;
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* Add a new driver variable */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
DriverVar *driver_add_new_variable(ChannelDriver *driver)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
DriverVar *dvar;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* sanity checks */
if (driver == NULL)
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* make a new variable */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar = MEM_callocN(sizeof(DriverVar), "DriverVar");
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
BLI_addtail(&driver->variables, dvar);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* give the variable a 'unique' name */
Refactor translation code out of blenfont - Add blentranslation `BLT_*` module. - moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`). - moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
2015-08-16 17:32:01 +10:00
strcpy(dvar->name, CTX_DATA_(BLT_I18NCONTEXT_ID_ACTION, "var"));
BLI_uniquename(&driver->variables, dvar, CTX_DATA_(BLT_I18NCONTEXT_ID_ACTION, "var"), '_',
More new data names translation (most cases should be covered now). Also done a few cleanup here and there...
2013-03-25 08:29:06 +00:00
offsetof(DriverVar, name), sizeof(dvar->name));
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* set the default type to 'single prop' */
driver_change_variable_type(dvar, DVAR_TYPE_SINGLE_PROP);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
fix for own but in recent driver optimization [#20580] Driver Crasher rev [25763] recalculate names when needed
2010-01-06 22:42:13 +00:00
/* since driver variables are cached, the expression needs re-compiling too */
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
BKE_driver_invalidate_expression(driver, false, true);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* return the target */
return dvar;
}
/* This frees the driver itself */
void fcurve_free_driver(FCurve *fcu)
{
ChannelDriver *driver;
DriverVar *dvar, *dvarn;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* sanity checks */
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
if (ELEM(NULL, fcu, fcu->driver))
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
return;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
driver = fcu->driver;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* free driver targets */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (dvar = driver->variables.first; dvar; dvar = dvarn) {
dvarn = dvar->next;
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
driver_free_variable_ex(driver, dvar);
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
rename and negate DISABLE_PYTHON --> WITH_PYTHON
2010-10-31 04:11:39 +00:00
#ifdef WITH_PYTHON
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* free compiled driver expression */
if (driver->expr_comp)
BPY_DECREF(driver->expr_comp);
#endif
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
BLI_expr_pylike_free(driver->expr_simple);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* free driver itself, then set F-Curve's point to this to NULL (as the curve may still be used) */
MEM_freeN(driver);
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fcu->driver = NULL;
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
/* This makes a copy of the given driver */
Make whole ID copying code use const source pointer. Noisy change, but safe, and better do it sooner than later if we are to rework copying code. Also, previous commit shows this *is* useful to catch some mistakes.
2017-06-14 22:36:30 +02:00
ChannelDriver *fcurve_copy_driver(const ChannelDriver *driver)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
ChannelDriver *ndriver;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* sanity checks */
if (driver == NULL)
return NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* copy all data */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
ndriver = MEM_dupallocN(driver);
ndriver->expr_comp = NULL;
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
ndriver->expr_simple = NULL;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* copy variables */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
BLI_listbase_clear(&ndriver->variables); /* to get rid of refs to non-copied data (that's still used on original) */
Drivers Editing: Added "Copy/Paste" buttons beside "Add Variable" for copying all variables from one driver to another This was a feature request from a few years back (IIRC from ZanQdo?) to make it easier to reuse one set of driver variables across several different drivers. Dev Notes: * Finally it's done! All that trouble for two little buttons. * Grr... cmake... grrr!
2016-04-15 20:04:07 +12:00
driver_variables_copy(&ndriver->variables, &driver->variables);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* return the new driver */
return ndriver;
}
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
/* Driver Expression Evaluation --------------- */
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
static ExprPyLike_Parsed *driver_compile_simple_expr_impl(ChannelDriver *driver)
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
{
/* Prepare parameter names. */
Cleanup: BLI_expr_pylike argument ordering - Order array length after the array. - Put return argument last.
2018-09-19 11:40:40 +10:00
int names_len = BLI_listbase_count(&driver->variables);
const char **names = BLI_array_alloca(names, names_len + 1);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
int i = 0;
names[i++] = "frame";
for (DriverVar *dvar = driver->variables.first; dvar; dvar = dvar->next) {
names[i++] = dvar->name;
}
Cleanup: BLI_expr_pylike argument ordering - Order array length after the array. - Put return argument last.
2018-09-19 11:40:40 +10:00
return BLI_expr_pylike_parse(driver->expression, names, names_len + 1);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
}
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
static bool driver_evaluate_simple_expr(ChannelDriver *driver, ExprPyLike_Parsed *expr, float *result, float time)
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
{
/* Prepare parameter values. */
Cleanup: BLI_expr_pylike argument ordering - Order array length after the array. - Put return argument last.
2018-09-19 11:40:40 +10:00
int vars_len = BLI_listbase_count(&driver->variables);
double *vars = BLI_array_alloca(vars, vars_len + 1);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
int i = 0;
vars[i++] = time;
for (DriverVar *dvar = driver->variables.first; dvar; dvar = dvar->next) {
vars[i++] = driver_get_variable_value(driver, dvar);
}
/* Evaluate expression. */
double result_val;
Cleanup: BLI_expr_pylike argument ordering - Order array length after the array. - Put return argument last.
2018-09-19 11:40:40 +10:00
eExprPyLike_EvalStatus status = BLI_expr_pylike_eval(expr, vars, vars_len + 1, &result_val);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
const char *message;
switch (status) {
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
case EXPR_PYLIKE_SUCCESS:
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
if (isfinite(result_val)) {
*result = (float)result_val;
}
return true;
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
case EXPR_PYLIKE_DIV_BY_ZERO:
case EXPR_PYLIKE_MATH_ERROR:
message = (status == EXPR_PYLIKE_DIV_BY_ZERO) ? "Division by Zero" : "Math Domain Error";
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "%s in Driver: '%s'", message, driver->expression);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
driver->flag |= DRIVER_FLAG_INVALID;
return true;
default:
/* arriving here means a bug, not user error */
Logging: Use CLOG for blenkernel Part of D4277 by @sobakasu
2019-02-01 12:44:19 +11:00
CLOG_ERROR(&LOG, "simple driver expression evaluation failed: '%s'", driver->expression);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
return false;
}
}
/* Compile and cache the driver expression if necessary, with thread safety. */
static bool driver_compile_simple_expr(ChannelDriver *driver)
{
if (driver->expr_simple != NULL) {
return true;
}
if (driver->type != DRIVER_TYPE_PYTHON) {
return false;
}
/* It's safe to parse in multiple threads; at worst it'll
* waste some effort, but in return avoids mutex contention. */
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
ExprPyLike_Parsed *expr = driver_compile_simple_expr_impl(driver);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
/* Store the result if the field is still NULL, or discard
* it if another thread got here first. */
Cleanup: style
2018-09-19 10:29:57 +10:00
if (atomic_cas_ptr((void **)&driver->expr_simple, NULL, expr) != NULL) {
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
BLI_expr_pylike_free(expr);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
}
return true;
}
/* Try using the simple expression evaluator to compute the result of the driver.
* On success, stores the result and returns true; on failure result is set to 0. */
static bool driver_try_evaluate_simple_expr(ChannelDriver *driver, ChannelDriver *driver_orig, float *result, float time)
{
*result = 0.0f;
return driver_compile_simple_expr(driver_orig) &&
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
BLI_expr_pylike_is_valid(driver_orig->expr_simple) &&
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
driver_evaluate_simple_expr(driver, driver_orig->expr_simple, result, time);
}
/* Check if the expression in the driver conforms to the simple subset. */
bool BKE_driver_has_simple_expression(ChannelDriver *driver)
{
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
return driver_compile_simple_expr(driver) && BLI_expr_pylike_is_valid(driver->expr_simple);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
}
/* Reset cached compiled expression data */
void BKE_driver_invalidate_expression(ChannelDriver *driver, bool expr_changed, bool varname_changed)
{
if (expr_changed || varname_changed) {
Cleanup: rename BLI_simple_expr -> BLI_expr_pylike_eval Simple isn't a good prefix for library names since lots of unrelated modules could be called 'simple'. Include 'py' in module name since this is a subset of Python, one of the main motivations for this is to be Python like/compatible.
2018-09-19 10:40:35 +10:00
BLI_expr_pylike_free(driver->expr_simple);
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
driver->expr_simple = NULL;
}
#ifdef WITH_PYTHON
if (expr_changed) {
driver->flag |= DRIVER_FLAG_RECOMPILE;
}
if (varname_changed) {
driver->flag |= DRIVER_FLAG_RENAMEVAR;
}
#endif
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* Driver Evaluation -------------------------- */
/* Evaluate a Driver Variable to get a value that contributes to the final */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
float driver_get_variable_value(ChannelDriver *driver, DriverVar *dvar)
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
{
Cleanup: use const for typeinfo
2015-03-30 21:17:07 +11:00
const DriverVarTypeInfo *dvti;
added support for proxies as drivers back.
2010-02-23 17:56:45 +00:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* sanity check */
if (ELEM(NULL, driver, dvar))
return 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* call the relevant callbacks to get the variable value
Drivers UI: Debug Info Feature request for ZanQdo, which shows the intermediate values used in driver calculations (i.e. current value of driver, and current value of variables), allowing drivers expressions to be debugged. This is a per-driver setting...
2010-01-19 23:38:26 +00:00
* using the variable type info, storing the obtained value
* in dvar->curval so that drivers can be debugged
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvti = get_dvar_typeinfo(dvar->type);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
if (dvti && dvti->get_value)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar->curval = dvti->get_value(driver, dvar);
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
else
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar->curval = 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Drivers UI: Debug Info Feature request for ZanQdo, which shows the intermediate values used in driver calculations (i.e. current value of driver, and current value of variables), allowing drivers expressions to be debugged. This is a per-driver setting...
2010-01-19 23:38:26 +00:00
return dvar->curval;
Drivers - Rotational Difference Restored the code to get this working. I haven't tested this to verify it, but it 'should' work... Also, deleted old gpencil.c file in editors, since it was causing compiling errors.
2009-04-20 10:45:25 +00:00
}
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* Evaluate an Channel-Driver to get a 'time' value to use instead of "evaltime"
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - "evaltime" is the frame at which F-Curve is being evaluated
* - has to return a float value
Merge branch 'master' into blender2.8
2018-11-14 17:12:52 +11:00
* - driver_orig is where we cache Python expressions, in case of COW
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
Drivers: ensure Python expressions are cached with copy-on-write. Store the compiled expressions on the original driver. Ref T55442.
2018-06-11 20:00:03 +02:00
float evaluate_driver(PathResolvedRNA *anim_rna, ChannelDriver *driver, ChannelDriver *driver_orig, const float evaltime)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
DriverVar *dvar;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* check if driver can be evaluated */
Drivers: ensure Python expressions are cached with copy-on-write. Store the compiled expressions on the original driver. Ref T55442.
2018-06-11 20:00:03 +02:00
if (driver_orig->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
return 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
switch (driver->type) {
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
case DRIVER_TYPE_AVERAGE: /* average values of driver targets */
driver type 'Sum'
2009-12-07 19:59:04 +00:00
case DRIVER_TYPE_SUM: /* sum values of driver targets */
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
{
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* check how many variables there are first (i.e. just one?) */
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
if (BLI_listbase_is_single(&driver->variables)) {
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
/* just one target, so just use that */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dvar = driver->variables.first;
driver->curval = driver_get_variable_value(driver, dvar);
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
}
else {
/* more than one target, so average the values of the targets */
float value = 0.0f;
Bugfix for Driver Evaluation: * Current value for drivers didn't get stored, which meant that the debug value never got updated to reflect the current state. * Min/Max variable types were not working
2010-01-20 00:54:06 +00:00
int tot = 0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
/* loop through targets, adding (hopefully we don't get any overflow!) */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (dvar = driver->variables.first; dvar; dvar = dvar->next) {
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
value += driver_get_variable_value(driver, dvar);
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
tot++;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* perform operations on the total if appropriate */
Bugfix #20384: target data path of driving not correct when loading old rig from 2.49b
2009-12-15 00:10:03 +00:00
if (driver->type == DRIVER_TYPE_AVERAGE)
remove redundant null checks and avoid divide by zero in driver evaluation
2013-07-13 05:53:14 +00:00
driver->curval = tot ? (value / (float)tot) : 0.0f;
driver type 'Sum'
2009-12-07 19:59:04 +00:00
else
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
driver->curval = value;
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
}
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
Animato - Drivers with Multiple Targets: Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'. These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand. By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :) For example, check the following diagram (thanks Cessen/Nathan V from Peach team): http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png TODO List: * Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects) * Graph Editor interface for editing these needs to be rewritten * Python function for evaluating these expressions is needed (Campbell?)
2009-04-16 07:37:06 +00:00
}
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
case DRIVER_TYPE_MIN: /* smallest value */
case DRIVER_TYPE_MAX: /* largest value */
{
float value = 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* loop through the variables, getting the values and comparing them to existing ones */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (dvar = driver->variables.first; dvar; dvar = dvar->next) {
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* get value */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
float tmp_val = driver_get_variable_value(driver, dvar);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
/* store this value if appropriate */
if (dvar->prev) {
/* check if greater/smaller than the baseline */
if (driver->type == DRIVER_TYPE_MAX) {
/* max? */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
if (tmp_val > value)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
value = tmp_val;
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
else {
/* min? */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
if (tmp_val < value)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
value = tmp_val;
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
}
else {
/* first item - make this the baseline for comparisons */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
value = tmp_val;
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix for Driver Evaluation: * Current value for drivers didn't get stored, which meant that the debug value never got updated to reflect the current state. * Min/Max variable types were not working
2010-01-20 00:54:06 +00:00
/* store value in driver */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
driver->curval = value;
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
Durian Request: Drivers Recode Highlights: * Support for Multi-Target Variables This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that. * New Variable Types With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones). * New Driver Types In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to. * Fix for Driver F-Curve colouring bug Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used. Notes: * This commit breaks existing 2.5 files with drivers (in other words, they are lost forever). * Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later. * Version patching for 2.49 files still needs to be put back in place.
2010-01-04 21:15:45 +00:00
}
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush 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 DRIVER_TYPE_PYTHON: /* expression */
{
/* check for empty or invalid expression */
Drivers: ensure Python expressions are cached with copy-on-write. Store the compiled expressions on the original driver. Ref T55442.
2018-06-11 20:00:03 +02:00
if ( (driver_orig->expression[0] == '\0') ||
(driver_orig->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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
driver->curval = 0.0f;
Bugfix for Driver Evaluation: * Current value for drivers didn't get stored, which meant that the debug value never got updated to reflect the current state. * Min/Max variable types were not working
2010-01-20 00:54:06 +00:00
}
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
else if (!driver_try_evaluate_simple_expr(driver, driver_orig, &driver->curval, evaltime)) {
#ifdef WITH_PYTHON
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
/* this evaluates the expression using Python, and returns its result:
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - on errors it reports, then returns 0.0f
Bugfix for Driver Evaluation: * Current value for drivers didn't get stored, which meant that the debug value never got updated to reflect the current state. * Min/Max variable types were not working
2010-01-20 00:54:06 +00:00
*/
Attempt to make drivers more safe for threading There were some reported data race conditions in the python interpreter which seems to be rather valid. Surely this is not very pretty solution, but it might solve some annoying bugs related on threading.
2015-05-18 13:52:01 +05:00
BLI_mutex_lock(&python_driver_lock);
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
Drivers: ensure Python expressions are cached with copy-on-write. Store the compiled expressions on the original driver. Ref T55442.
2018-06-11 20:00:03 +02:00
driver->curval = BPY_driver_exec(anim_rna, driver, driver_orig, evaltime);
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
Attempt to make drivers more safe for threading There were some reported data race conditions in the python interpreter which seems to be rather valid. Surely this is not very pretty solution, but it might solve some annoying bugs related on threading.
2015-05-18 13:52:01 +05:00
BLI_mutex_unlock(&python_driver_lock);
pydrivers: 'frame' is now in the driver namespace, - no need to link to scenes when using a frame from the pydriver, this made linking rigs for eg, quite messy. - advantage that we get subframe values (where scenes from was fixed to a whole number).
2011-11-17 07:08:09 +00:00
#else /* WITH_PYTHON*/
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
UNUSED_VARS(anim_rna, evaltime);
rename and negate DISABLE_PYTHON --> WITH_PYTHON
2010-10-31 04:11:39 +00:00
#endif /* WITH_PYTHON*/
Support evaluating simple driver expressions without Python interpreter. Recently @sergey found that hard-coding evaluation of certain very common driver expressions without calling the Python interpreter produces a 30-40% performance improvement. Since hard-coding is obviously not suitable for production, I implemented a proper parser and interpreter for simple arithmetic expressions in C. The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=, and, or, not, ternary if; driver variables, frame, pi, True, False, and a subset of standard math functions that seem most useful. Booleans are represented as numbers, since within the supported operation set it seems to be impossible to distinguish True/False from 1.0/0.0. Boolean operations properly implement lazy evaluation with jumps, and comparisons support chaining like 'a < b < c...'. Expressions are parsed into a very simple stack machine program that can then be safely evaluated in multiple threads. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D3698
2018-09-15 15:32:40 +03:00
}
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
Animato - Driver + ShapeKey bugfixes * ShapeKey conversions should now go to the correct places * Added fix for drivers to prevent crashes when no driver object is provided (Franky from BBB seems to have one such driver for some reason). * Temporarily disabled a check when evaluating drivers for whether the driver is tagged for evaluation. Drivers still need to be correctly tagged AND ordered by the Depsgraph to work correctly.
2009-01-28 00:50: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
default:
{
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* special 'hack' - just use stored value
Cleanup: comment blocks
2018-09-02 18:28:27 +10:00
* This is currently used as the mechanism which allows animated settings to be able
* to be changed via the UI.
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
code cleanup: add break statements in switch ()'s, (even at the last case).
2013-07-21 08:16:37 +00:00
break;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Bugfix for Driver Evaluation: * Current value for drivers didn't get stored, which meant that the debug value never got updated to reflect the current state. * Min/Max variable types were not working
2010-01-20 00:54:06 +00:00
/* return value for driver */
return driver->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
}
/* ***************************** Curve Calculations ********************************* */
/* The total length of the handles is not allowed to be more
* than the horizontal distance between (v1-v4).
* This is to prevent curve loops.
style cleanup / comment formatting for bli/bke/bmesh
2012-03-03 20:19:11 +00:00
*/
code cleanup: use float vector size in function definitions, and const's where the values are unchanged.
2012-02-28 14:05:00 +00:00
void correct_bezpart(float v1[2], float v2[2], float v3[2], float v4[2])
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
float h1[2], h2[2], len1, len2, len, fac;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* calculate handle deltas */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
h1[0] = v1[0] - v2[0];
h1[1] = v1[1] - v2[1];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
h2[0] = v4[0] - v3[0];
h2[1] = v4[1] - v3[1];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* calculate distances:
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - len = span of time between keyframes
* - len1 = length of handle of start key
* - len2 = length of handle of end key
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
len = v4[0] - v1[0];
len1 = fabsf(h1[0]);
len2 = fabsf(h2[0]);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* if the handles have no length, no need to do any corrections */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if ((len1 + len2) == 0.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
return;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* the two handles cross over each other, so force them
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
* apart using the proportion they overlap
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if ((len1 + len2) > len) {
fac = len / (len1 + len2);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
v2[0] = (v1[0] - fac * h1[0]);
v2[1] = (v1[1] - fac * h1[1]);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
v3[0] = (v4[0] - fac * h2[0]);
v3[1] = (v4[1] - fac * h2[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
}
}
/* find root ('zero') */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static int findzero(float x, float q0, float q1, float q2, float q3, float *o)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
double c0, c1, c2, c3, a, b, c, p, q, d, t, phi;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
int nr = 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
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
c0 = q0 - x;
c1 = 3.0f * (q1 - q0);
c2 = 3.0f * (q0 - 2.0f * q1 + q2);
c3 = q3 - q0 + 3.0f * (q1 - q2);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
if (c3 != 0.0) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
a = c2 / c3;
b = c1 / c3;
c = c0 / c3;
a = a / 3;
p = b / 3 - a * a;
q = (2 * a * a * a - a * b + c) / 2;
d = q * q + p * p * p;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
if (d > 0.0) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
t = sqrt(d);
o[0] = (float)(sqrt3d(-q + t) + sqrt3d(-q - t) - a);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
blenkernel: floats were being implicitly promoted to doubles, adjust to use floats.
2011-03-28 04:22:50 +00:00
if ((o[0] >= (float)SMALL) && (o[0] <= 1.000001f)) 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
else return 0;
}
else if (d == 0.0) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
t = sqrt3d(-q);
o[0] = (float)(2 * t - a);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
blenkernel: floats were being implicitly promoted to doubles, adjust to use floats.
2011-03-28 04:22:50 +00:00
if ((o[0] >= (float)SMALL) && (o[0] <= 1.000001f)) nr++;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
o[nr] = (float)(-t - a);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if ((o[nr] >= (float)SMALL) && (o[nr] <= 1.000001f)) return nr + 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
else return nr;
}
else {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
phi = acos(-q / sqrt(-(p * p * p)));
t = sqrt(-p);
p = cos(phi / 3);
q = sqrt(3 - 3 * p * p);
o[0] = (float)(2 * t * p - a);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
blenkernel: floats were being implicitly promoted to doubles, adjust to use floats.
2011-03-28 04:22:50 +00:00
if ((o[0] >= (float)SMALL) && (o[0] <= 1.000001f)) nr++;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
o[nr] = (float)(-t * (p + q) - a);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
blenkernel: floats were being implicitly promoted to doubles, adjust to use floats.
2011-03-28 04:22:50 +00:00
if ((o[nr] >= (float)SMALL) && (o[nr] <= 1.000001f)) nr++;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
o[nr] = (float)(-t * (p - q) - a);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if ((o[nr] >= (float)SMALL) && (o[nr] <= 1.000001f)) return nr + 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
else return nr;
}
}
else {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
a = c2;
b = c1;
c = c0;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
if (a != 0.0) {
style cleanup
2012-07-07 22:51:57 +00:00
/* discriminant */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
p = b * b - 4 * a * c;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
if (p > 0) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
p = sqrt(p);
o[0] = (float)((-b - p) / (2 * a));
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
blenkernel: floats were being implicitly promoted to doubles, adjust to use floats.
2011-03-28 04:22:50 +00:00
if ((o[0] >= (float)SMALL) && (o[0] <= 1.000001f)) nr++;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
o[nr] = (float)((-b + p) / (2 * a));
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if ((o[nr] >= (float)SMALL) && (o[nr] <= 1.000001f)) return nr + 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
else return nr;
}
else if (p == 0) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
o[0] = (float)(-b / (2 * a));
blenkernel: floats were being implicitly promoted to doubles, adjust to use floats.
2011-03-28 04:22:50 +00:00
if ((o[0] >= (float)SMALL) && (o[0] <= 1.000001f)) 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
else return 0;
}
}
else if (b != 0.0) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
o[0] = (float)(-c / b);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
blenkernel: floats were being implicitly promoted to doubles, adjust to use floats.
2011-03-28 04:22:50 +00:00
if ((o[0] >= (float)SMALL) && (o[0] <= 1.000001f)) 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
else return 0;
}
else if (c == 0.0) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
o[0] = 0.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
return 1;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +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
}
}
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static void berekeny(float f1, float f2, float f3, float f4, float *o, int b)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
float t, c0, c1, c2, c3;
int a;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
c0 = f1;
c1 = 3.0f * (f2 - f1);
c2 = 3.0f * (f1 - 2.0f * f2 + f3);
c3 = f4 - f1 + 3.0f * (f2 - f3);
for (a = 0; a < b; a++) {
t = o[a];
o[a] = c0 + t * c1 + t * t * c2 + t * t * t * c3;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
}
/* -------------------------- */
/* Calculate F-Curve value for 'evaltime' using BezTriple keyframes */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static float fcurve_eval_keyframes(FCurve *fcu, BezTriple *bezts, float evaltime)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
Math Lib: add shell_v3v3_normalized_to_dist and v2 version bypass angle calculation to avoids (asin, sqrt, cos).
2014-04-19 22:12:50 +10:00
const float eps = 1.e-8f;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
BezTriple *bezt, *prevbezt, *lastbezt;
float v1[2], v2[2], v3[2], v4[2], opl[32], dx, fac;
Animato - Support for 'BuiltIn' and 'Relative' Keying Sets When inserting keyframes in the 3D-View (support will be extended to other editors in due course) using the IKEY hotkey, the menu which appears will now consist of 3 parts: * 'Active Keying Set' - this option allows you to use the user-defined KeyingSet which is active for the current scene (i.e. the one seen in the TimeLine/Outliner headers) * User defined Keying Sets - a list of all such available KeyingSets is included, and entries can be chosen from there * Built-In Keying Sets - see later... To achieve this, several changes needed to be made first: * Added support for 'relative' in addition to 'absolute' Keying Sets. Relative Keying Sets are Keying Sets which operate on data from the current context (i.e. a 'location' KeyingSet will add location keyframes for selected objects/bones/nodes as opposed to location keyframes for some particular object). The is a tentative 'templates' requirement system here, which still needs to be fully fleshed out. * Added support for builtin Keying Sets (i.e. 'Location', 'Rotation', 'Scaling', and 'LocRot' as a few initial demonstrations), which replaces the temporary Insert Keyframe operator for the 3D-View (IKEY). These are effectively relative Keying Set definitions which are included in Blender by default and stored in a list separate from user-defined ones. Volunteer help in defining a few more of these for other editors will be welcome soon. * Removed/replaced much of the crappy temporary Keyframing operator code, though a few tweaks could still be done.
2009-03-31 22:36:13 +00:00
unsigned int a;
int b;
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
float cvalue = 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* get pointers */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
a = fcu->totvert - 1;
prevbezt = bezts;
bezt = prevbezt + 1;
lastbezt = prevbezt + a;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* evaluation time at or past endpoints? */
style cleanup, brackets in else/if, some indentation.
2012-03-06 18:40:15 +00:00
if (prevbezt->vec[1][0] >= evaltime) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* before or on first keyframe */
2.5 - Fixes for animating enum values Interpolation between keyframes for enum values (and booleans) can only be constant now. TODO: A way to do this for modifiers is still needed.
2009-05-28 01:57:29 +00:00
if ( (fcu->extend == FCURVE_EXTRAPOLATE_LINEAR) && (prevbezt->ipo != BEZT_IPO_CONST) &&
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
!(fcu->flag & FCURVE_DISCRETE_VALUES) )
2.5 - Fixes for animating enum values Interpolation between keyframes for enum values (and booleans) can only be constant now. TODO: A way to do this for modifiers is still needed.
2009-05-28 01:57:29 +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
/* linear or bezier interpolation */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (prevbezt->ipo == BEZT_IPO_LIN) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* Use the next center point instead of our own handle for
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
* linear interpolated extrapolate
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
if (fcu->totvert == 1) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = prevbezt->vec[1][1];
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
}
else {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
bezt = prevbezt + 1;
dx = prevbezt->vec[1][0] - evaltime;
fac = bezt->vec[1][0] - prevbezt->vec[1][0];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* prevent division by zero */
if (fac) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fac = (bezt->vec[1][1] - prevbezt->vec[1][1]) / fac;
cvalue = prevbezt->vec[1][1] - (fac * dx);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = prevbezt->vec[1][1];
style cleanup - braces & else / if's
2012-03-07 04:53:43 +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
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* Use the first handle (earlier) of first BezTriple to calculate the
* gradient and thus the value of the curve at evaltime
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dx = prevbezt->vec[1][0] - evaltime;
fac = prevbezt->vec[1][0] - prevbezt->vec[0][0];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* prevent division by zero */
if (fac) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fac = (prevbezt->vec[1][1] - prevbezt->vec[0][1]) / fac;
cvalue = prevbezt->vec[1][1] - (fac * dx);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = prevbezt->vec[1][1];
style cleanup - braces & else / if's
2012-03-07 04:53:43 +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
}
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* constant (BEZT_IPO_HORIZ) extrapolation or constant interpolation,
* so just extend first keyframe's 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
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = prevbezt->vec[1][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
}
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else if (lastbezt->vec[1][0] <= evaltime) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* after or on last keyframe */
2.5 - Fixes for animating enum values Interpolation between keyframes for enum values (and booleans) can only be constant now. TODO: A way to do this for modifiers is still needed.
2009-05-28 01:57:29 +00:00
if ( (fcu->extend == FCURVE_EXTRAPOLATE_LINEAR) && (lastbezt->ipo != BEZT_IPO_CONST) &&
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
!(fcu->flag & FCURVE_DISCRETE_VALUES) )
2.5 - Fixes for animating enum values Interpolation between keyframes for enum values (and booleans) can only be constant now. TODO: A way to do this for modifiers is still needed.
2009-05-28 01:57:29 +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
/* linear or bezier interpolation */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
if (lastbezt->ipo == BEZT_IPO_LIN) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* Use the next center point instead of our own handle for
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
* linear interpolated extrapolate
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
if (fcu->totvert == 1) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = lastbezt->vec[1][1];
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
}
else {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
prevbezt = lastbezt - 1;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dx = evaltime - lastbezt->vec[1][0];
fac = lastbezt->vec[1][0] - prevbezt->vec[1][0];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* prevent division by zero */
if (fac) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fac = (lastbezt->vec[1][1] - prevbezt->vec[1][1]) / fac;
cvalue = lastbezt->vec[1][1] + (fac * dx);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = lastbezt->vec[1][1];
style cleanup - braces & else / if's
2012-03-07 04:53:43 +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
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* Use the gradient of the second handle (later) of last BezTriple to calculate the
* gradient and thus the value of the curve at evaltime
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
dx = evaltime - lastbezt->vec[1][0];
fac = lastbezt->vec[2][0] - lastbezt->vec[1][0];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* prevent division by zero */
if (fac) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
fac = (lastbezt->vec[2][1] - lastbezt->vec[1][1]) / fac;
cvalue = lastbezt->vec[1][1] + (fac * dx);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = lastbezt->vec[1][1];
style cleanup - braces & else / if's
2012-03-07 04:53:43 +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
}
}
style cleanup - braces & else / if's
2012-03-07 04:53:43 +00:00
else {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* constant (BEZT_IPO_HORIZ) extrapolation or constant interpolation,
* so just extend last keyframe's 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
*/
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = lastbezt->vec[1][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
}
}
style cleanup, brackets in else/if, some indentation.
2012-03-06 18:40:15 +00:00
else {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* evaltime occurs somewhere in the middle of the curve */
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
bool exact = false;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Regression Bugfix T40332: Bad driver behaviour on small distances. !!! ANIMATORS/RIGGERS PLEASE TEST !!! I've reduced the size of the threshold for the keyframe lookup here. This threshold determines the minimum time in frames between keyframes (i.e. "how close" to each other they can get). Making this too small causes problems like T39207, but it seems that the threshold we've been using makes it impossible to get accurate behaviour on driver curves with keyframes, when the driver target only moves 2cm (i.e. 0.02 BU). So far, all of the test cases from T39207 seem to work fine, as well as Caminandes 2 files, and Kenny the Caterpillar. The Kiribati rigs/shots (thanks jpbouza for helping to check on these!) also seem to be fine.
2014-06-11 15:48:43 +12:00
/* Use binary search to find appropriate keyframes...
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
*
Regression Bugfix T40332: Bad driver behaviour on small distances. !!! ANIMATORS/RIGGERS PLEASE TEST !!! I've reduced the size of the threshold for the keyframe lookup here. This threshold determines the minimum time in frames between keyframes (i.e. "how close" to each other they can get). Making this too small causes problems like T39207, but it seems that the threshold we've been using makes it impossible to get accurate behaviour on driver curves with keyframes, when the driver target only moves 2cm (i.e. 0.02 BU). So far, all of the test cases from T39207 seem to work fine, as well as Caminandes 2 files, and Kenny the Caterpillar. The Kiribati rigs/shots (thanks jpbouza for helping to check on these!) also seem to be fine.
2014-06-11 15:48:43 +12:00
* The threshold here has the following constraints:
* - 0.001 is too coarse -> We get artifacts with 2cm driver movements at 1BU = 1m (see T40332)
* - 0.00001 is too fine -> Weird errors, like selecting the wrong keyframe range (see T39207), occur.
* This lower bound was established in b888a32eee8147b028464336ad2404d8155c64dd
*/
a = binarysearch_bezt_index_ex(bezts, evaltime, fcu->totvert, 0.0001, &exact);
Fix for unlikely NULL pointer dereference Potential crash reading freestyle modifiers from future blend-files
2015-02-20 17:17:36 +11:00
if (G.debug & G_DEBUG) printf("eval fcurve '%s' - %f => %u/%u, %d\n", fcu->rna_path, evaltime, a, fcu->totvert, exact);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
if (exact) {
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* index returned must be interpreted differently when it sits on top of an existing keyframe
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
* - that keyframe is the start of the segment we need (see action_bug_2.blend in T39207)
*/
prevbezt = bezts + a;
bezt = (a < fcu->totvert - 1) ? (prevbezt + 1) : prevbezt;
}
else {
/* index returned refers to the keyframe that the eval-time occurs *before*
* - hence, that keyframe marks the start of the segment we're dealing with
*/
bezt = bezts + a;
prevbezt = (a > 0) ? (bezt - 1) : bezt;
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T36209: Use binary search function for evaluating F-Curves This provides a speedup to evaluating long F-Curves in fcurve_eval_keyframes() by using the pre-existing binarysearch_bezt_index() function (used for keyframe insertion) to find the relevant BezTriple on the FCurve at the current evaltime. The current code loops over all BezTriples (sometimes not even breaking from the loop after cvalue has been evaluated). Reviewer Notes: - Unlike in the original patch, we use the old/existing logic instead of checking that (exact == true). See comments in code and also on the tracker entry for this patch for more details. Patch By: Josh Wedlake
2014-03-15 11:45:14 +13:00
/* use if the key is directly on the frame, rare cases this is needed else we get 0.0 instead. */
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13:00
/* XXX: consult T39207 for examples of files where failure of these checks can cause issues */
if (exact) {
cvalue = prevbezt->vec[1][1];
}
Math Lib: add shell_v3v3_normalized_to_dist and v2 version bypass angle calculation to avoids (asin, sqrt, cos).
2014-04-19 22:12:50 +10:00
else if (fabsf(bezt->vec[1][0] - evaltime) < eps) {
Patch T36209: Use binary search function for evaluating F-Curves This provides a speedup to evaluating long F-Curves in fcurve_eval_keyframes() by using the pre-existing binarysearch_bezt_index() function (used for keyframe insertion) to find the relevant BezTriple on the FCurve at the current evaltime. The current code loops over all BezTriples (sometimes not even breaking from the loop after cvalue has been evaluated). Reviewer Notes: - Unlike in the original patch, we use the old/existing logic instead of checking that (exact == true). See comments in code and also on the tracker entry for this patch for more details. Patch By: Josh Wedlake
2014-03-15 11:45:14 +13:00
cvalue = bezt->vec[1][1];
}
/* evaltime occurs within the interval defined by these two keyframes */
else if ((prevbezt->vec[1][0] <= evaltime) && (bezt->vec[1][0] >= evaltime)) {
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
const float begin = prevbezt->vec[1][1];
const float change = bezt->vec[1][1] - prevbezt->vec[1][1];
const float duration = bezt->vec[1][0] - prevbezt->vec[1][0];
const float time = evaltime - prevbezt->vec[1][0];
f-curve easing: Adjustments to Robert Penner elastic easing Compensate for the clamped amplitude by blending the elastic effect. Allows for a subtle elastic effect which wasn't possible before.
2014-04-29 05:31:50 +10:00
const float amplitude = prevbezt->amplitude;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
const float period = prevbezt->period;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T36209: Use binary search function for evaluating F-Curves This provides a speedup to evaluating long F-Curves in fcurve_eval_keyframes() by using the pre-existing binarysearch_bezt_index() function (used for keyframe insertion) to find the relevant BezTriple on the FCurve at the current evaltime. The current code loops over all BezTriples (sometimes not even breaking from the loop after cvalue has been evaluated). Reviewer Notes: - Unlike in the original patch, we use the old/existing logic instead of checking that (exact == true). See comments in code and also on the tracker entry for this patch for more details. Patch By: Josh Wedlake
2014-03-15 11:45:14 +13:00
/* value depends on interpolation mode */
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
if ((prevbezt->ipo == BEZT_IPO_CONST) || (fcu->flag & FCURVE_DISCRETE_VALUES) || (duration == 0)) {
Patch T36209: Use binary search function for evaluating F-Curves This provides a speedup to evaluating long F-Curves in fcurve_eval_keyframes() by using the pre-existing binarysearch_bezt_index() function (used for keyframe insertion) to find the relevant BezTriple on the FCurve at the current evaltime. The current code loops over all BezTriples (sometimes not even breaking from the loop after cvalue has been evaluated). Reviewer Notes: - Unlike in the original patch, we use the old/existing logic instead of checking that (exact == true). See comments in code and also on the tracker entry for this patch for more details. Patch By: Josh Wedlake
2014-03-15 11:45:14 +13:00
/* constant (evaltime not relevant, so no interpolation needed) */
cvalue = prevbezt->vec[1][1];
in rare cases fcurves with no handle length can result in 0.0. check if the point matches the frame.
2010-02-18 19:43:13 +00:00
}
Patch T36209: Use binary search function for evaluating F-Curves This provides a speedup to evaluating long F-Curves in fcurve_eval_keyframes() by using the pre-existing binarysearch_bezt_index() function (used for keyframe insertion) to find the relevant BezTriple on the FCurve at the current evaltime. The current code loops over all BezTriples (sometimes not even breaking from the loop after cvalue has been evaluated). Reviewer Notes: - Unlike in the original patch, we use the old/existing logic instead of checking that (exact == true). See comments in code and also on the tracker entry for this patch for more details. Patch By: Josh Wedlake
2014-03-15 11:45:14 +13:00
else {
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
switch (prevbezt->ipo) {
/* interpolation ...................................... */
case BEZT_IPO_BEZ:
/* bezier interpolation */
/* (v1, v2) are the first keyframe and its 2nd handle */
v1[0] = prevbezt->vec[1][0];
v1[1] = prevbezt->vec[1][1];
v2[0] = prevbezt->vec[2][0];
v2[1] = prevbezt->vec[2][1];
/* (v3, v4) are the last keyframe's 1st handle + the last keyframe */
v3[0] = bezt->vec[0][0];
v3[1] = bezt->vec[0][1];
v4[0] = bezt->vec[1][0];
v4[1] = bezt->vec[1][1];
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
[T40372] FCurve Eval/Drawing Optimisation: Skip Bezier handle eval when all handles are flat Small optimisation (which shouldn't have much of an effect) where we skip complex handle calculations if all the handles/verts for a Bezier curve segment are all flat. Patch by Campbell (T40372 -> F91346)
2014-11-16 22:30:42 +13:00
if (fabsf(v1[1] - v4[1]) < FLT_EPSILON &&
fabsf(v2[1] - v3[1]) < FLT_EPSILON &&
fabsf(v3[1] - v4[1]) < FLT_EPSILON)
{
/* Optimisation: If all the handles are flat/at the same values,
* the value is simply the shared value (see T40372 -> F91346)
*/
cvalue = v1[1];
SCons: correct include for win, also minor cleanup
2014-11-24 09:33:12 +01:00
}
else {
[T40372] FCurve Eval/Drawing Optimisation: Skip Bezier handle eval when all handles are flat Small optimisation (which shouldn't have much of an effect) where we skip complex handle calculations if all the handles/verts for a Bezier curve segment are all flat. Patch by Campbell (T40372 -> F91346)
2014-11-16 22:30:42 +13:00
/* adjust handles so that they don't overlap (forming a loop) */
correct_bezpart(v1, v2, v3, v4);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
[T40372] FCurve Eval/Drawing Optimisation: Skip Bezier handle eval when all handles are flat Small optimisation (which shouldn't have much of an effect) where we skip complex handle calculations if all the handles/verts for a Bezier curve segment are all flat. Patch by Campbell (T40372 -> F91346)
2014-11-16 22:30:42 +13:00
/* try to get a value for this position - if failure, try another set of points */
b = findzero(evaltime, v1[0], v2[0], v3[0], v4[0], opl);
if (b) {
berekeny(v1[1], v2[1], v3[1], v4[1], opl, 1);
cvalue = opl[0];
/* break; */
}
else {
if (G.debug & G_DEBUG) printf(" ERROR: findzero() failed at %f with %f %f %f %f\n", evaltime, v1[0], v2[0], v3[0], v4[0]);
}
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_LIN:
/* linear - simply linearly interpolate between values of the two keyframes */
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_linear_ease(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
/* easing ............................................ */
case BEZT_IPO_BACK:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_back_ease_in(time, begin, change, duration, prevbezt->back);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_back_ease_out(time, begin, change, duration, prevbezt->back);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_back_ease_in_out(time, begin, change, duration, prevbezt->back);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease out */
cvalue = BLI_easing_back_ease_out(time, begin, change, duration, prevbezt->back);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_BOUNCE:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_bounce_ease_in(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_bounce_ease_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_bounce_ease_in_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease out */
cvalue = BLI_easing_bounce_ease_out(time, begin, change, duration);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_CIRC:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_circ_ease_in(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_circ_ease_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_circ_ease_in_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease in */
cvalue = BLI_easing_circ_ease_in(time, begin, change, duration);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
case BEZT_IPO_CUBIC:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_cubic_ease_in(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_cubic_ease_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_cubic_ease_in_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease in */
cvalue = BLI_easing_cubic_ease_in(time, begin, change, duration);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_ELASTIC:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_elastic_ease_in(time, begin, change, duration, amplitude, period);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_elastic_ease_out(time, begin, change, duration, amplitude, period);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_elastic_ease_in_out(time, begin, change, duration, amplitude, period);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease out */
cvalue = BLI_easing_elastic_ease_out(time, begin, change, duration, amplitude, period);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_EXPO:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_expo_ease_in(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_expo_ease_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_expo_ease_in_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease in */
cvalue = BLI_easing_expo_ease_in(time, begin, change, duration);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_QUAD:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quad_ease_in(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quad_ease_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quad_ease_in_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease in */
cvalue = BLI_easing_quad_ease_in(time, begin, change, duration);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_QUART:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quart_ease_in(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quart_ease_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quart_ease_in_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease in */
cvalue = BLI_easing_quart_ease_in(time, begin, change, duration);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_QUINT:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quint_ease_in(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quint_ease_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_quint_ease_in_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease in */
cvalue = BLI_easing_quint_ease_in(time, begin, change, duration);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
case BEZT_IPO_SINE:
switch (prevbezt->easing) {
case BEZT_IPO_EASE_IN:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_sine_ease_in(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_sine_ease_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
case BEZT_IPO_EASE_IN_OUT:
Code cleanup: rename easing functions with BLI_easing_ prefix
2014-03-25 09:57:37 +11:00
cvalue = BLI_easing_sine_ease_in_out(time, begin, change, duration);
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
"Auto" option for Keyframe.easing This option (alongside the Ease In/Out/InOut options already available) aims to make it easier to get an initial curve that looks closer to the one you were expecting, by automatically picking whether Ease In or Ease Out should be used based on the type of interpolation being used for the curve segment in question. Notes: * The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in) * This does break compatability with files saved in previous dev builds, but only if you were using Bounce/Elastic/Back with "Ease In"
2014-04-28 01:42:51 +12:00
default: /* default/auto: same as ease in */
cvalue = BLI_easing_sine_ease_in(time, begin, change, duration);
break;
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
}
break;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Patch T22084: Robert Penner Easing Equations for FCurves This commit introduces support for a number of new interpolation types which are useful for motion-graphics work. These define a number of "easing equations" (basically, equations which define some preset ways that one keyframe transitions to another) which reduce the amount of manual work (inserting and tweaking keyframes) to achieve certain common effects. For example, snappy movements, and fake-physics such as bouncing/springing effects. The additional interpolation types introduced in this commit can be found in many packages and toolkits (notably Qt and all modern web browsers). For more info and a few live demos, see [1] and [2]. Credits: * Dan Eicher (dna) - Original patch * Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase * Joshua Leung (aligorith) - Code review and a few polishing tweaks Additional Resources: [1] http://easings.net [2] http://www.robertpenner.com/easing/
2014-03-22 02:50:24 +13:00
default:
cvalue = prevbezt->vec[1][1];
break;
Fix T39207: FCurve evaluation regressions following 2aff243 (again) Yet another attempt at fixing the problems here. This time, I've added a new function/version of the binary search utility so that we can pass in custom thresholds (Note: This ability is only used for evaluation currently, with everything else using a wrapper which still uses the old default threshold), making it ok to start trusting the "exact" parameter.
2014-03-21 14:24:15 +13: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
}
}
Fix T39207: FCurve evaluation regressions following 2aff243 This commit attempts to fix some of the FCurve evaluation regressions arising from an earlier commit to speed up the process using binary search. Further tweaks may still be needed though to get this to an acceptable level of reliability (namely, tuning the threshold defining which keyframes get considered "close together"). Since we're still in an early stage of the 2.71 dev cycle, for now it's still worth trying to get this working instead of simply reverting this (which can still be done later if it proves too problematic). Specific fixes: * The previous code was somewhat dangerous in that it allowed out-of-bounds accessing of memory when a == 0. It turns out this was more common than originally anticipated (as the assert I added here ended up failing in the "action_bug.blend" file in the report) * Tweaked the code used to test for closely-spaced points so that the "Clive.blend" example for driver curves won't fail. The approach used here has the downside though that since "exact" uses a might coarser threshold for equality, there may be some precision loss issues causing backwards compat issues (namely with closely spaced keyframes, or for certain NLA strips). For now, I've left in some debug prints that can be enabled by running Blender in debug mode (i.e. "blender -d"), which can provide some useful tuning info should we need to look more into our approach here.
2014-03-20 02:19:35 +13:00
else {
Debug prints weren't getting triggered, since they no longer use the old flag
2014-03-21 12:55:10 +13:00
if (G.debug & G_DEBUG) printf(" ERROR: failed eval - p=%f b=%f, t=%f (%f)\n", prevbezt->vec[1][0], bezt->vec[1][0], evaltime, fabsf(bezt->vec[1][0] - evaltime));
Fix T39207: FCurve evaluation regressions following 2aff243 This commit attempts to fix some of the FCurve evaluation regressions arising from an earlier commit to speed up the process using binary search. Further tweaks may still be needed though to get this to an acceptable level of reliability (namely, tuning the threshold defining which keyframes get considered "close together"). Since we're still in an early stage of the 2.71 dev cycle, for now it's still worth trying to get this working instead of simply reverting this (which can still be done later if it proves too problematic). Specific fixes: * The previous code was somewhat dangerous in that it allowed out-of-bounds accessing of memory when a == 0. It turns out this was more common than originally anticipated (as the assert I added here ended up failing in the "action_bug.blend" file in the report) * Tweaked the code used to test for closely-spaced points so that the "Clive.blend" example for driver curves won't fail. The approach used here has the downside though that since "exact" uses a might coarser threshold for equality, there may be some precision loss issues causing backwards compat issues (namely with closely spaced keyframes, or for certain NLA strips). For now, I've left in some debug prints that can be enabled by running Blender in debug mode (i.e. "blender -d"), which can provide some useful tuning info should we need to look more into our approach here.
2014-03-20 02:19:35 +13: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
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* return value */
return cvalue;
}
/* Calculate F-Curve value for 'evaltime' using FPoint samples */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
static float fcurve_eval_samples(FCurve *fcu, FPoint *fpts, float evaltime)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
FPoint *prevfpt, *lastfpt, *fpt;
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
float cvalue = 0.0f;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* get pointers */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
prevfpt = fpts;
lastfpt = prevfpt + fcu->totvert - 1;
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* evaluation time at or past endpoints? */
if (prevfpt->vec[0] >= evaltime) {
/* before or on first sample, so just extend value */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = prevfpt->vec[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
}
else if (lastfpt->vec[0] <= evaltime) {
/* after or on last sample, so just extend value */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = lastfpt->vec[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
}
else {
Fix for baked FCurve subframe interpolation (bad abs use)
2014-03-01 14:12:11 +11:00
float t = fabsf(evaltime - floorf(evaltime));
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* find the one on the right frame (assume that these are spaced on 1-frame intervals) */
Fix T46701: Sampled FCurve looks jagged when FModifiers (doing nothing) are present This was caused by interpolation between samples being performed incorrectly (i.e. wrong order of arguments) when sampling more than once per frame.
2015-11-14 18:08:36 +13:00
fpt = prevfpt + ((int)evaltime - (int)prevfpt->vec[0]);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Animation Visualisation Cleanups - Part 2: * Finished baking code for motion paths, generalising it so that it works for both Objects and Bones. It is based on the old code for baking bones, although I have modified the updating code to use a more 'correct' method of updating dependencies. However, this may turn out to be too slow, and another API method should be added for that... * Moved some of the old version-patching code for animviz settings out of the drawing functions, instead doing this on the version patching proper. * Added RNA support for the new AnimViz types, and included RNA access via their users too. The old settings have still been left in for now, since there are still some things not ready to use yet. ---- * F-Curve's with sample points (i.e. sounds to F-Curves) now perform linear interpolation between sample points instead of using constant interpolation.
2010-01-07 22:54:05 +00:00
/* if not exactly on the frame, perform linear interpolation with the next one */
Fix T46701: Sampled FCurve looks jagged when FModifiers (doing nothing) are present This was caused by interpolation between samples being performed incorrectly (i.e. wrong order of arguments) when sampling more than once per frame.
2015-11-14 18:08:36 +13:00
if ((t != 0.0f) && (t < 1.0f))
cvalue = interpf(fpt->vec[1], (fpt + 1)->vec[1], 1.0f - t);
Animation Visualisation Cleanups - Part 2: * Finished baking code for motion paths, generalising it so that it works for both Objects and Bones. It is based on the old code for baking bones, although I have modified the updating code to use a more 'correct' method of updating dependencies. However, this may turn out to be too slow, and another API method should be added for that... * Moved some of the old version-patching code for animviz settings out of the drawing functions, instead doing this on the version patching proper. * Added RNA support for the new AnimViz types, and included RNA access via their users too. The old settings have still been left in for now, since there are still some things not ready to use yet. ---- * F-Curve's with sample points (i.e. sounds to F-Curves) now perform linear interpolation between sample points instead of using constant interpolation.
2010-01-07 22:54:05 +00:00
else
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cvalue = fpt->vec[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
}
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
/* return value */
return cvalue;
}
/* ***************************** F-Curve - Evaluation ********************************* */
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* Evaluate and return the value of the given F-Curve at the specified frame ("evaltime")
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
* Note: this is also used for drivers
*/
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
static float evaluate_fcurve_ex(FCurve *fcu, float evaltime, float cvalue)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
Fix crash happening in Cycles fcurve modifier Summary: Crash was happening because of fcurve modifier stack used modifier's DNA to store temporary data. Now made it so storage for such a thing is being allocated locally per object update so multiple objects which shares the same animation wouldn't run into threading conflict anymore. This storage might be a part of EvaluationContext, but that'd mean passing this context all over in object_where_is which will clutter API for now without actual benefit for this. Optimization notes: storage is only being allocated if there're Cycles modifier in the stack, so there're no extra allocations happening in all other cases. To make code a bit less cluttered with this storage passing all over the place added extra callbacks to the FModifier storage which runs evaluation with the given storage. Reviewers: brecht, campbellbarton, aligorith CC: plasmasolutions Differential Revision: https://developer.blender.org/D147
2013-12-29 19:15:37 +06:00
FModifierStackStorage *storage;
F-Curve Modifiers: Time-Modifying F-Modifiers Cleanup Time-Modifying F-Curve Modifiers now get special callbacks to allow them to specify what frame they need to be evaluated on, instead of forcing a re-evaluation of the preceeding curve + modifier-stack. This should be more robust than the old way in general. It still remains to be seen if some tweaks to this are still needed, as the full consequences of the propogation of modified time-spaces have yet to be fully explored. For now though, evaluation works by finding the last modifier on the stack which modifies time, and asks it what time it modifies the given time to. This modified time is used to evaluate the F-Curve data only. The modifier stack gets evaluated using the original time instead.
2009-05-03 13:00:59 +00:00
float devaltime;
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
/* evaluate modifiers which modify time to evaluate the base curve at */
storage = evaluate_fmodifiers_storage_new(&fcu->modifiers);
devaltime = evaluate_time_fmodifiers(storage, &fcu->modifiers, fcu, cvalue, evaltime);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* evaluate curve-data
Cleanup: comment block tabs
2018-11-14 12:53:15 +11:00
* - 'devaltime' instead of 'evaltime', as this is the time that the last time-modifying
* F-Curve modifier on the stack requested the curve to be evaluated at
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
*/
if (fcu->bezt)
cvalue = fcurve_eval_keyframes(fcu, fcu->bezt, devaltime);
else if (fcu->fpt)
cvalue = fcurve_eval_samples(fcu, fcu->fpt, devaltime);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
/* evaluate modifiers */
evaluate_value_fmodifiers(storage, &fcu->modifiers, fcu, &cvalue, devaltime);
evaluate_fmodifiers_storage_free(storage);
/* if curve can only have integral values, perform truncation (i.e. drop the decimal part)
* here so that the curve can be sampled correctly
*/
if (fcu->flag & FCURVE_INT_VALUES)
cvalue = floorf(cvalue + 0.5f);
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
/* return evaluated value */
return cvalue;
}
float evaluate_fcurve(FCurve *fcu, float evaltime)
{
BLI_assert(fcu->driver == NULL);
return evaluate_fcurve_ex(fcu, evaltime, 0.0);
}
Fix: allow curve of driver to be evaluated individually This is necessary when adding a new keyframe to a fcurve that also has a driver. Reviewers: brecht, campbellbarton Differential Revision: https://developer.blender.org/D4278
2019-01-31 12:17:43 +01:00
float evaluate_fcurve_only_curve(FCurve *fcu, float evaltime)
{
/* Can be used to evaluate the (keyframed) fcurve only.
* Also works for driver-fcurves when the driver itself is not relevant.
* E.g. when inserting a keyframe in a driver fcurve. */
return evaluate_fcurve_ex(fcu, evaltime, 0.0);
}
Drivers: ensure Python expressions are cached with copy-on-write. Store the compiled expressions on the original driver. Ref T55442.
2018-06-11 20:00:03 +02:00
float evaluate_fcurve_driver(PathResolvedRNA *anim_rna, FCurve *fcu, ChannelDriver *driver_orig, float evaltime)
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
{
BLI_assert(fcu->driver != NULL);
float cvalue = 0.0f;
/* if there is a driver (only if this F-Curve is acting as 'driver'), evaluate it to find value to use as "evaltime"
F-Curve Modifiers: Time-Modifying F-Modifiers Cleanup Time-Modifying F-Curve Modifiers now get special callbacks to allow them to specify what frame they need to be evaluated on, instead of forcing a re-evaluation of the preceeding curve + modifier-stack. This should be more robust than the old way in general. It still remains to be seen if some tweaks to this are still needed, as the full consequences of the propogation of modified time-spaces have yet to be fully explored. For now though, evaluation works by finding the last modifier on the stack which modifies time, and asks it what time it modifies the given time to. This modified time is used to evaluate the F-Curve data only. The modifier stack gets evaluated using the original time instead.
2009-05-03 13:00:59 +00:00
* since drivers essentially act as alternative input (i.e. in place of 'time') for F-Curves
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*/
if (fcu->driver) {
/* evaltime now serves as input for the curve */
Drivers: ensure Python expressions are cached with copy-on-write. Store the compiled expressions on the original driver. Ref T55442.
2018-06-11 20:00:03 +02:00
evaltime = evaluate_driver(anim_rna, fcu->driver, driver_orig, evaltime);
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
Bugfix [#36950] Restrict Frame Range not being obeyed on Driver F-Curves By default, drivers (used to) automatically map the driver result (i.e. "evaltime" or the x-coordinates in the driver graphs) to results. This evaltime => cvalue mapping is necessary when there are absolutely no keyframes or modifiers on a driver F-Curve, or else nothing would happen. However, when there are modifiers on these driver F-Curves, and these modifiers only work within certain ranges, there would be confusing and unwanted situations where even if you clamped the modifiers to only generating a curve within certain frame ranges, the final driver output would still ignore the results of the curve due to the underlying 1-1 mapping. This commit introduces a check to ensure that this automatic mapping won't happen during such invalid ranges.
2013-11-04 04:18:28 +00:00
/* only do a default 1-1 mapping if it's unlikely that anything else will set a value... */
if (fcu->totvert == 0) {
FModifier *fcm;
bool do_linear = true;
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
/* out-of-range F-Modifiers will block, as will those which just plain overwrite the values
Bugfix [#36950] Restrict Frame Range not being obeyed on Driver F-Curves By default, drivers (used to) automatically map the driver result (i.e. "evaltime" or the x-coordinates in the driver graphs) to results. This evaltime => cvalue mapping is necessary when there are absolutely no keyframes or modifiers on a driver F-Curve, or else nothing would happen. However, when there are modifiers on these driver F-Curves, and these modifiers only work within certain ranges, there would be confusing and unwanted situations where even if you clamped the modifiers to only generating a curve within certain frame ranges, the final driver output would still ignore the results of the curve due to the underlying 1-1 mapping. This commit introduces a check to ensure that this automatic mapping won't happen during such invalid ranges.
2013-11-04 04:18:28 +00:00
* XXX: additive is a bit more dicey; it really depends then if things are in range or not...
*/
for (fcm = fcu->modifiers.first; fcm; fcm = fcm->next) {
/* if there are range-restrictions, we must definitely block [#36950] */
if ((fcm->flag & FMODIFIER_FLAG_RANGERESTRICT) == 0 ||
((fcm->sfra <= evaltime) && (fcm->efra >= evaltime)) )
{
/* within range: here it probably doesn't matter, though we'd want to check on additive... */
}
else {
/* outside range: modifier shouldn't contribute to the curve here, though it does in other areas,
* so neither should the driver!
*/
do_linear = false;
}
}
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
Bugfix [#36950] Restrict Frame Range not being obeyed on Driver F-Curves By default, drivers (used to) automatically map the driver result (i.e. "evaltime" or the x-coordinates in the driver graphs) to results. This evaltime => cvalue mapping is necessary when there are absolutely no keyframes or modifiers on a driver F-Curve, or else nothing would happen. However, when there are modifiers on these driver F-Curves, and these modifiers only work within certain ranges, there would be confusing and unwanted situations where even if you clamped the modifiers to only generating a curve within certain frame ranges, the final driver output would still ignore the results of the curve due to the underlying 1-1 mapping. This commit introduces a check to ensure that this automatic mapping won't happen during such invalid ranges.
2013-11-04 04:18:28 +00:00
/* only copy over results if none of the modifiers disagreed with this */
if (do_linear) {
cvalue = evaltime;
}
}
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
Fix crash happening in Cycles fcurve modifier Summary: Crash was happening because of fcurve modifier stack used modifier's DNA to store temporary data. Now made it so storage for such a thing is being allocated locally per object update so multiple objects which shares the same animation wouldn't run into threading conflict anymore. This storage might be a part of EvaluationContext, but that'd mean passing this context all over in object_where_is which will clutter API for now without actual benefit for this. Optimization notes: storage is only being allocated if there're Cycles modifier in the stack, so there're no extra allocations happening in all other cases. To make code a bit less cluttered with this storage passing all over the place added extra callbacks to the FModifier storage which runs evaluation with the given storage. Reviewers: brecht, campbellbarton, aligorith CC: plasmasolutions Differential Revision: https://developer.blender.org/D147
2013-12-29 19:15:37 +06:00
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
return evaluate_fcurve_ex(fcu, evaltime, cvalue);
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
}
/* Calculate the value of the given F-Curve at the given frame, and set its curval */
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
float calculate_fcurve(PathResolvedRNA *anim_rna, FCurve *fcu, float evaltime)
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
{
Cleanup: trailing space for blenkernel
2018-06-17 17:05:51 +02:00
/* only calculate + set curval (overriding the existing value) if curve has
NLA SoC: Bugfix for Deleting Keyframes When an F-Curve doesn't contain any keyframes anymore but it still exists, the F-Curve's value is not recalculated and flushed anymore if the F-Curve's value will not change. That is, if the F-Curve doesn't have any other data, i.e. drivers or generator-modifiers, which would still change its value, it wouldn't be recalculated to have a value of zero. This solves the problem of deleting all scale keyframes, whereby objects/bones would appear to 'vanish'
2009-06-19 04:58:40 +00:00
* any data which warrants this...
*/
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
if ((fcu->totvert) || (fcu->driver && !(fcu->driver->flag & DRIVER_FLAG_INVALID)) ||
list_has_suitable_fmodifier(&fcu->modifiers, 0, FMI_TYPE_GENERATE_CURVE))
NLA SoC: Bugfix for Deleting Keyframes When an F-Curve doesn't contain any keyframes anymore but it still exists, the F-Curve's value is not recalculated and flushed anymore if the F-Curve's value will not change. That is, if the F-Curve doesn't have any other data, i.e. drivers or generator-modifiers, which would still change its value, it wouldn't be recalculated to have a value of zero. This solves the problem of deleting all scale keyframes, whereby objects/bones would appear to 'vanish'
2009-06-19 04:58:40 +00:00
{
/* calculate and set curval (evaluates driver too if necessary) */
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
float curval;
if (fcu->driver) {
Drivers: ensure Python expressions are cached with copy-on-write. Store the compiled expressions on the original driver. Ref T55442.
2018-06-11 20:00:03 +02:00
curval = evaluate_fcurve_driver(anim_rna, fcu, fcu->driver, evaltime);
Py-Driver: add 'self' option Drivers can use this to refer to the data which the driver is applied to, useful for objects, bones, to avoid having to create a variable pointing to its self.
2016-07-30 16:34:01 +10:00
}
else {
curval = evaluate_fcurve(fcu, evaltime);
}
Fix T48234: Glitch w/ action constraints sharing an action FCurve evaluation depended on FCurve.curval, which isn't threadsafe. Now only use this value for debug display, and pass the value instead of storing in the FCurve for all but debug-display.
2016-06-04 00:54:28 +10:00
fcu->curval = curval; /* debug display only, not thread safe! */
return curval;
}
else {
return 0.0f;
NLA SoC: Bugfix for Deleting Keyframes When an F-Curve doesn't contain any keyframes anymore but it still exists, the F-Curve's value is not recalculated and flushed anymore if the F-Curve's value will not change. That is, if the F-Curve doesn't have any other data, i.e. drivers or generator-modifiers, which would still change its value, it wouldn't be recalculated to have a value of zero. This solves the problem of deleting all scale keyframes, whereby objects/bones would appear to 'vanish'
2009-06-19 04:58:40 +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
}
Copy Permalink