2011-02-23 10:52:22 +00:00
|
|
|
/*
|
2009-02-13 01:51:33 +00:00
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2009-02-13 01:51:33 +00:00
|
|
|
*
|
2009-08-27 06:03:41 +00:00
|
|
|
* Contributor(s): Blender Foundation (2009), Joshua Leung
|
2009-02-13 01:51:33 +00:00
|
|
|
*
|
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
|
*/
|
|
|
|
|
|
2011-02-27 20:20:01 +00:00
|
|
|
/** \file blender/makesrna/intern/rna_animation.c
|
|
|
|
|
* \ingroup RNA
|
|
|
|
|
*/
|
|
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
|
|
|
|
|
#include "DNA_anim_types.h"
|
|
|
|
|
#include "DNA_action_types.h"
|
|
|
|
|
#include "DNA_scene_types.h"
|
|
|
|
|
|
2012-06-29 09:16:59 +00:00
|
|
|
#include "BLI_utildefines.h"
|
|
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2013-03-07 02:44:55 +00:00
|
|
|
#include "RNA_access.h"
|
|
|
|
|
#include "RNA_define.h"
|
|
|
|
|
#include "RNA_enum_types.h"
|
|
|
|
|
|
|
|
|
|
#include "rna_internal.h"
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
2011-01-12 07:16:24 +00:00
|
|
|
#include "WM_types.h"
|
|
|
|
|
|
2013-03-07 02:44:55 +00:00
|
|
|
#include "ED_keyframing.h"
|
|
|
|
|
|
2009-08-25 04:05:37 +00:00
|
|
|
/* exported for use in API */
|
|
|
|
|
EnumPropertyItem keyingset_path_grouping_items[] = {
|
|
|
|
|
{KSP_GROUP_NAMED, "NAMED", 0, "Named Group", ""},
|
|
|
|
|
{KSP_GROUP_NONE, "NONE", 0, "None", ""},
|
|
|
|
|
{KSP_GROUP_KSNAME, "KEYINGSET", 0, "Keying Set Name", ""},
|
2012-05-12 11:01:29 +00:00
|
|
|
{0, NULL, 0, NULL, NULL}
|
|
|
|
|
};
|
2009-08-25 04:05:37 +00:00
|
|
|
|
2012-12-23 13:58:42 +00:00
|
|
|
/* It would be cool to get rid of this 'INSERTKEY_' prefix in 'py strings' values, but it would break existing
|
|
|
|
|
* exported keyingset... :/
|
|
|
|
|
*/
|
|
|
|
|
EnumPropertyItem keying_flag_items[] = {
|
|
|
|
|
{INSERTKEY_NEEDED, "INSERTKEY_NEEDED", 0, "Only Needed",
|
|
|
|
|
"Only insert keyframes where they're needed in the relevant F-Curves"},
|
|
|
|
|
{INSERTKEY_MATRIX, "INSERTKEY_VISUAL", 0, "Visual Keying",
|
|
|
|
|
"Insert keyframes based on 'visual transforms'"},
|
|
|
|
|
{INSERTKEY_XYZ2RGB, "INSERTKEY_XYZ_TO_RGB", 0, "XYZ=RGB Colors",
|
|
|
|
|
"Color for newly added transformation F-Curves (Location, Rotation, Scale) "
|
|
|
|
|
"and also Color is based on the transform axis"},
|
|
|
|
|
{0, NULL, 0, NULL, NULL}
|
|
|
|
|
};
|
|
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
#ifdef RNA_RUNTIME
|
|
|
|
|
|
2012-11-07 12:31:05 +00:00
|
|
|
#include "BLI_math_base.h"
|
|
|
|
|
|
2010-04-04 17:42:40 +00:00
|
|
|
#include "BKE_animsys.h"
|
2011-04-26 13:49:40 +00:00
|
|
|
#include "BKE_fcurve.h"
|
2011-01-12 01:17:13 +00:00
|
|
|
#include "BKE_nla.h"
|
|
|
|
|
|
|
|
|
|
#include "WM_api.h"
|
2010-04-04 17:42:40 +00:00
|
|
|
|
2009-08-02 13:15:20 +00:00
|
|
|
static int rna_AnimData_action_editable(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
AnimData *adt = (AnimData *)ptr->data;
|
2009-08-02 13:15:20 +00:00
|
|
|
|
|
|
|
|
/* active action is only editable when it is not a tweaking strip */
|
|
|
|
|
if ((adt->flag & ADT_NLA_EDIT_ON) || (adt->actstrip) || (adt->tmpact))
|
|
|
|
|
return 0;
|
|
|
|
|
else
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2011-04-19 13:01:50 +00:00
|
|
|
static void rna_AnimData_action_set(PointerRNA *ptr, PointerRNA value)
|
|
|
|
|
{
|
|
|
|
|
ID *ownerId = (ID *)ptr->id.data;
|
2011-07-07 03:35:48 +00:00
|
|
|
BKE_animdata_set_action(NULL, ownerId, value.data);
|
2011-04-19 13:01:50 +00:00
|
|
|
}
|
|
|
|
|
|
2009-10-14 09:08:53 +00:00
|
|
|
/* ****************************** */
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* wrapper for poll callback */
|
|
|
|
|
static int RKS_POLL_rna_internal(KeyingSetInfo *ksi, bContext *C)
|
|
|
|
|
{
|
2011-10-19 22:40:03 +00:00
|
|
|
extern FunctionRNA rna_KeyingSetInfo_poll_func;
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
void *ret;
|
|
|
|
|
int ok;
|
|
|
|
|
|
|
|
|
|
RNA_pointer_create(NULL, ksi->ext.srna, ksi, &ptr);
|
2012-03-05 23:30:41 +00:00
|
|
|
func = &rna_KeyingSetInfo_poll_func; /* RNA_struct_find_function(&ptr, "poll"); */
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
2012-05-12 11:01:29 +00:00
|
|
|
{
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* hook up arguments */
|
|
|
|
|
RNA_parameter_set_lookup(&list, "ksi", &ksi);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "context", &C);
|
|
|
|
|
|
|
|
|
|
/* execute the function */
|
2010-12-07 04:12:15 +00:00
|
|
|
ksi->ext.call(C, &ptr, func, &list);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
/* read the result */
|
|
|
|
|
RNA_parameter_get_lookup(&list, "ok", &ret);
|
2012-05-12 11:01:29 +00:00
|
|
|
ok = *(int *)ret;
|
|
|
|
|
}
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_parameter_list_free(&list);
|
|
|
|
|
|
|
|
|
|
return ok;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* wrapper for iterator callback */
|
|
|
|
|
static void RKS_ITER_rna_internal(KeyingSetInfo *ksi, bContext *C, KeyingSet *ks)
|
|
|
|
|
{
|
2011-10-19 22:40:03 +00:00
|
|
|
extern FunctionRNA rna_KeyingSetInfo_iterator_func;
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
|
|
|
|
|
RNA_pointer_create(NULL, ksi->ext.srna, ksi, &ptr);
|
2012-03-05 23:30:41 +00:00
|
|
|
func = &rna_KeyingSetInfo_iterator_func; /* RNA_struct_find_function(&ptr, "poll"); */
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
2012-05-12 11:01:29 +00:00
|
|
|
{
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* hook up arguments */
|
|
|
|
|
RNA_parameter_set_lookup(&list, "ksi", &ksi);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "context", &C);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "ks", &ks);
|
|
|
|
|
|
|
|
|
|
/* execute the function */
|
2010-12-07 04:12:15 +00:00
|
|
|
ksi->ext.call(C, &ptr, func, &list);
|
2012-05-12 11:01:29 +00:00
|
|
|
}
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_parameter_list_free(&list);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* wrapper for generator callback */
|
|
|
|
|
static void RKS_GEN_rna_internal(KeyingSetInfo *ksi, bContext *C, KeyingSet *ks, PointerRNA *data)
|
|
|
|
|
{
|
2011-10-19 22:40:03 +00:00
|
|
|
extern FunctionRNA rna_KeyingSetInfo_generate_func;
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
|
|
|
|
|
RNA_pointer_create(NULL, ksi->ext.srna, ksi, &ptr);
|
2012-03-05 23:30:41 +00:00
|
|
|
func = &rna_KeyingSetInfo_generate_func; /* RNA_struct_find_generate(&ptr, "poll"); */
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
2012-05-12 11:01:29 +00:00
|
|
|
{
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* hook up arguments */
|
|
|
|
|
RNA_parameter_set_lookup(&list, "ksi", &ksi);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "context", &C);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "ks", &ks);
|
2010-03-18 07:53:46 +00:00
|
|
|
RNA_parameter_set_lookup(&list, "data", data);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
/* execute the function */
|
2010-12-07 04:12:15 +00:00
|
|
|
ksi->ext.call(C, &ptr, func, &list);
|
2012-05-12 11:01:29 +00:00
|
|
|
}
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_parameter_list_free(&list);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ------ */
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
/* XXX: the exact purpose of this is not too clear... maybe we want to revise this at some point? */
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
static StructRNA *rna_KeyingSetInfo_refine(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSetInfo *ksi = (KeyingSetInfo *)ptr->data;
|
2012-05-12 11:01:29 +00:00
|
|
|
return (ksi->ext.srna) ? ksi->ext.srna : &RNA_KeyingSetInfo;
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
}
|
|
|
|
|
|
2011-05-18 10:56:26 +00:00
|
|
|
static void rna_KeyingSetInfo_unregister(Main *bmain, StructRNA *type)
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSetInfo *ksi = RNA_struct_blender_type_get(type);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
if (ksi == NULL)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* free RNA data referencing this */
|
|
|
|
|
RNA_struct_free_extension(type, &ksi->ext);
|
|
|
|
|
RNA_struct_free(&BLENDER_RNA, type);
|
|
|
|
|
|
2013-01-09 13:15:23 +00:00
|
|
|
WM_main_add_notifier(NC_WINDOW, NULL);
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* unlink Blender-side data */
|
2011-05-18 10:56:26 +00:00
|
|
|
ANIM_keyingset_info_unregister(bmain, ksi);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
}
|
|
|
|
|
|
2012-03-18 09:27:36 +00:00
|
|
|
static StructRNA *rna_KeyingSetInfo_register(Main *bmain, ReportList *reports, void *data, const char *identifier,
|
|
|
|
|
StructValidateFunc validate, StructCallbackFunc call, StructFreeFunc free)
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
{
|
2011-03-03 17:58:06 +00:00
|
|
|
KeyingSetInfo dummyksi = {NULL};
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
KeyingSetInfo *ksi;
|
2011-03-03 17:58:06 +00:00
|
|
|
PointerRNA dummyptr = {{NULL}};
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
int have_function[3];
|
|
|
|
|
|
|
|
|
|
/* setup dummy type info to store static properties in */
|
2012-03-05 23:30:41 +00:00
|
|
|
/* TODO: perhaps we want to get users to register as if they're using 'KeyingSet' directly instead? */
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_pointer_create(NULL, &RNA_KeyingSetInfo, &dummyksi, &dummyptr);
|
|
|
|
|
|
|
|
|
|
/* validate the python class */
|
|
|
|
|
if (validate(&dummyptr, data, have_function) != 0)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2010-03-24 12:48:03 +00:00
|
|
|
if (strlen(identifier) >= sizeof(dummyksi.idname)) {
|
2012-03-08 14:04:06 +00:00
|
|
|
BKE_reportf(reports, RPT_ERROR, "Registering keying set info class: '%s' is too long, maximum length is %d",
|
|
|
|
|
identifier, (int)sizeof(dummyksi.idname));
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* check if we have registered this info before, and remove it */
|
2012-05-05 16:03:57 +00:00
|
|
|
ksi = ANIM_keyingset_info_find_name(dummyksi.idname);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
if (ksi && ksi->ext.srna)
|
2011-05-18 10:56:26 +00:00
|
|
|
rna_KeyingSetInfo_unregister(bmain, ksi->ext.srna);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
/* create a new KeyingSetInfo type */
|
2012-03-05 23:30:41 +00:00
|
|
|
ksi = MEM_callocN(sizeof(KeyingSetInfo), "python keying set info");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
memcpy(ksi, &dummyksi, sizeof(KeyingSetInfo));
|
|
|
|
|
|
|
|
|
|
/* set RNA-extensions info */
|
2013-01-09 05:32:15 +00:00
|
|
|
ksi->ext.srna = RNA_def_struct_ptr(&BLENDER_RNA, ksi->idname, &RNA_KeyingSetInfo);
|
2012-03-05 23:30:41 +00:00
|
|
|
ksi->ext.data = data;
|
|
|
|
|
ksi->ext.call = call;
|
|
|
|
|
ksi->ext.free = free;
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_struct_blender_type_set(ksi->ext.srna, ksi);
|
|
|
|
|
|
|
|
|
|
/* set callbacks */
|
2012-03-05 23:30:41 +00:00
|
|
|
/* NOTE: we really should have all of these... */
|
2012-05-12 11:01:29 +00:00
|
|
|
ksi->poll = (have_function[0]) ? RKS_POLL_rna_internal : NULL;
|
|
|
|
|
ksi->iter = (have_function[1]) ? RKS_ITER_rna_internal : NULL;
|
|
|
|
|
ksi->generate = (have_function[2]) ? RKS_GEN_rna_internal : NULL;
|
2010-12-28 11:50:10 +00:00
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* add and register with other info as needed */
|
2010-10-16 14:32:17 +00:00
|
|
|
ANIM_keyingset_info_register(ksi);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
2013-01-09 13:15:23 +00:00
|
|
|
WM_main_add_notifier(NC_WINDOW, NULL);
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* return the struct-rna added */
|
|
|
|
|
return ksi->ext.srna;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ****************************** */
|
|
|
|
|
|
2009-10-14 09:08:53 +00:00
|
|
|
static StructRNA *rna_ksPath_id_typef(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
KS_Path *ksp = (KS_Path *)ptr->data;
|
2009-10-14 09:08:53 +00:00
|
|
|
return ID_code_to_RNA_type(ksp->idtype);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int rna_ksPath_id_editable(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
KS_Path *ksp = (KS_Path *)ptr->data;
|
|
|
|
|
return (ksp->idtype) ? PROP_EDITABLE : 0;
|
2009-10-14 09:08:53 +00:00
|
|
|
}
|
|
|
|
|
|
2009-11-13 01:04:01 +00:00
|
|
|
static void rna_ksPath_id_type_set(PointerRNA *ptr, int value)
|
|
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
KS_Path *data = (KS_Path *)(ptr->data);
|
2009-11-13 01:04:01 +00:00
|
|
|
|
|
|
|
|
/* set the driver type, then clear the id-block if the type is invalid */
|
2012-03-05 23:30:41 +00:00
|
|
|
data->idtype = value;
|
2009-11-13 01:04:01 +00:00
|
|
|
if ((data->id) && (GS(data->id->name) != data->idtype))
|
2012-03-05 23:30:41 +00:00
|
|
|
data->id = NULL;
|
2009-11-13 01:04:01 +00:00
|
|
|
}
|
|
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
static void rna_ksPath_RnaPath_get(PointerRNA *ptr, char *value)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KS_Path *ksp = (KS_Path *)ptr->data;
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
if (ksp->rna_path)
|
|
|
|
|
strcpy(value, ksp->rna_path);
|
|
|
|
|
else
|
2012-03-05 23:30:41 +00:00
|
|
|
value[0] = '\0';
|
2009-02-13 01:51:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int rna_ksPath_RnaPath_length(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KS_Path *ksp = (KS_Path *)ptr->data;
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
if (ksp->rna_path)
|
|
|
|
|
return strlen(ksp->rna_path);
|
|
|
|
|
else
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void rna_ksPath_RnaPath_set(PointerRNA *ptr, const char *value)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KS_Path *ksp = (KS_Path *)ptr->data;
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
if (ksp->rna_path)
|
2009-04-05 11:26:33 +00:00
|
|
|
MEM_freeN(ksp->rna_path);
|
2009-02-13 01:51:33 +00:00
|
|
|
|
2011-09-28 05:20:14 +00:00
|
|
|
if (value[0])
|
2012-03-05 23:30:41 +00:00
|
|
|
ksp->rna_path = BLI_strdup(value);
|
|
|
|
|
else
|
|
|
|
|
ksp->rna_path = NULL;
|
2009-02-13 01:51:33 +00:00
|
|
|
}
|
|
|
|
|
|
2009-10-14 09:08:53 +00:00
|
|
|
/* ****************************** */
|
2009-10-03 04:21:38 +00:00
|
|
|
|
2012-11-06 05:04:54 +00:00
|
|
|
static void rna_KeyingSet_name_set(PointerRNA *ptr, const char *value)
|
|
|
|
|
{
|
|
|
|
|
KeyingSet *ks = (KeyingSet *)ptr->data;
|
|
|
|
|
|
|
|
|
|
/* update names of corresponding groups if name changes */
|
|
|
|
|
if (strcmp(ks->name, value)) {
|
|
|
|
|
KS_Path *ksp;
|
|
|
|
|
|
|
|
|
|
for (ksp = ks->paths.first; ksp; ksp = ksp->next) {
|
|
|
|
|
if ((ksp->groupmode == KSP_GROUP_KSNAME) && (ksp->id)) {
|
|
|
|
|
AnimData *adt = BKE_animdata_from_id(ksp->id);
|
|
|
|
|
|
|
|
|
|
/* TODO: NLA strips? */
|
|
|
|
|
if (adt && adt->action) {
|
|
|
|
|
bActionGroup *agrp;
|
|
|
|
|
|
|
|
|
|
/* lazy check - should really find the F-Curve for the affected path and check its group
|
|
|
|
|
* but this way should be faster and work well for most cases, as long as there are no
|
|
|
|
|
* conflicts
|
|
|
|
|
*/
|
|
|
|
|
for (agrp = adt->action->groups.first; agrp; agrp = agrp->next) {
|
|
|
|
|
if (strcmp(ks->name, agrp->name) == 0) {
|
|
|
|
|
/* there should only be one of these in the action, so can stop... */
|
|
|
|
|
BLI_strncpy(agrp->name, value, sizeof(agrp->name));
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* finally, update name to new value */
|
|
|
|
|
BLI_strncpy(ks->name, value, sizeof(ks->name));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2009-10-03 04:21:38 +00:00
|
|
|
static int rna_KeyingSet_active_ksPath_editable(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSet *ks = (KeyingSet *)ptr->data;
|
2009-10-03 04:21:38 +00:00
|
|
|
|
|
|
|
|
/* only editable if there are some paths to change to */
|
|
|
|
|
return (ks->paths.first != NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static PointerRNA rna_KeyingSet_active_ksPath_get(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSet *ks = (KeyingSet *)ptr->data;
|
2012-05-12 11:01:29 +00:00
|
|
|
return rna_pointer_inherit_refine(ptr, &RNA_KeyingSetPath, BLI_findlink(&ks->paths, ks->active_path - 1));
|
2009-10-03 04:21:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void rna_KeyingSet_active_ksPath_set(PointerRNA *ptr, PointerRNA value)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSet *ks = (KeyingSet *)ptr->data;
|
2012-05-12 11:01:29 +00:00
|
|
|
KS_Path *ksp = (KS_Path *)value.data;
|
2012-03-05 23:30:41 +00:00
|
|
|
ks->active_path = BLI_findindex(&ks->paths, ksp) + 1;
|
2009-10-03 04:21:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int rna_KeyingSet_active_ksPath_index_get(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSet *ks = (KeyingSet *)ptr->data;
|
2012-05-12 11:01:29 +00:00
|
|
|
return MAX2(ks->active_path - 1, 0);
|
2009-10-03 04:21:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void rna_KeyingSet_active_ksPath_index_set(PointerRNA *ptr, int value)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSet *ks = (KeyingSet *)ptr->data;
|
2012-05-12 11:01:29 +00:00
|
|
|
ks->active_path = value + 1;
|
2009-10-03 04:21:38 +00:00
|
|
|
}
|
|
|
|
|
|
2012-03-30 16:09:05 +00:00
|
|
|
static void rna_KeyingSet_active_ksPath_index_range(PointerRNA *ptr, int *min, int *max, int *softmin, int *softmax)
|
2009-10-03 04:21:38 +00:00
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSet *ks = (KeyingSet *)ptr->data;
|
2009-10-03 04:21:38 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
*min = 0;
|
2012-11-07 12:31:05 +00:00
|
|
|
*max = max_ii(0, BLI_countlist(&ks->paths) - 1);
|
2009-10-03 04:21:38 +00:00
|
|
|
}
|
|
|
|
|
|
2010-03-25 11:34:18 +00:00
|
|
|
static PointerRNA rna_KeyingSet_typeinfo_get(PointerRNA *ptr)
|
|
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
KeyingSet *ks = (KeyingSet *)ptr->data;
|
2010-03-25 11:34:18 +00:00
|
|
|
KeyingSetInfo *ksi = NULL;
|
|
|
|
|
|
|
|
|
|
/* keying set info is only for builtin Keying Sets */
|
2012-03-05 23:30:41 +00:00
|
|
|
if ((ks->flag & KEYINGSET_ABSOLUTE) == 0)
|
2012-05-05 16:03:57 +00:00
|
|
|
ksi = ANIM_keyingset_info_find_name(ks->typeinfo);
|
2010-03-25 11:34:18 +00:00
|
|
|
return rna_pointer_inherit_refine(ptr, &RNA_KeyingSetInfo, ksi);
|
|
|
|
|
}
|
|
|
|
|
|
2010-04-04 17:42:40 +00:00
|
|
|
|
|
|
|
|
|
2012-03-18 09:27:36 +00:00
|
|
|
static KS_Path *rna_KeyingSet_paths_add(KeyingSet *keyingset, ReportList *reports,
|
2012-05-12 11:01:29 +00:00
|
|
|
ID *id, const char rna_path[], int index, int group_method, const char group_name[])
|
2010-04-04 17:42:40 +00:00
|
|
|
{
|
|
|
|
|
KS_Path *ksp = NULL;
|
|
|
|
|
short flag = 0;
|
|
|
|
|
|
|
|
|
|
/* special case when index = -1, we key the whole array (as with other places where index is used) */
|
|
|
|
|
if (index == -1) {
|
|
|
|
|
flag |= KSP_FLAG_WHOLE_ARRAY;
|
|
|
|
|
index = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* if data is valid, call the API function for this */
|
|
|
|
|
if (keyingset) {
|
2012-03-05 23:30:41 +00:00
|
|
|
ksp = BKE_keyingset_add_path(keyingset, id, group_name, rna_path, index, flag, group_method);
|
2012-03-18 09:27:36 +00:00
|
|
|
keyingset->active_path = BLI_countlist(&keyingset->paths);
|
2010-04-04 17:42:40 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2012-10-21 14:02:30 +00:00
|
|
|
BKE_report(reports, RPT_ERROR, "Keying set path could not be added");
|
2010-04-04 17:42:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* return added path */
|
|
|
|
|
return ksp;
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-02 09:41:26 +00:00
|
|
|
static void rna_KeyingSet_paths_remove(KeyingSet *keyingset, ReportList *reports, PointerRNA *ksp_ptr)
|
2010-04-04 17:42:40 +00:00
|
|
|
{
|
2012-11-02 09:41:26 +00:00
|
|
|
KS_Path *ksp = ksp_ptr->data;
|
|
|
|
|
|
2010-04-04 17:42:40 +00:00
|
|
|
/* if data is valid, call the API function for this */
|
2012-11-02 09:41:26 +00:00
|
|
|
if ((keyingset && ksp) == FALSE) {
|
2012-10-21 14:02:30 +00:00
|
|
|
BKE_report(reports, RPT_ERROR, "Keying set path could not be removed");
|
2012-11-02 09:41:26 +00:00
|
|
|
return;
|
2010-04-04 17:42:40 +00:00
|
|
|
}
|
2012-11-02 09:41:26 +00:00
|
|
|
|
|
|
|
|
/* remove the active path from the KeyingSet */
|
|
|
|
|
BKE_keyingset_free_path(keyingset, ksp);
|
|
|
|
|
RNA_POINTER_INVALIDATE(ksp_ptr);
|
|
|
|
|
|
|
|
|
|
/* the active path number will most likely have changed */
|
|
|
|
|
/* TODO: we should get more fancy and actually check if it was removed, but this will do for now */
|
|
|
|
|
keyingset->active_path = 0;
|
2010-04-04 17:42:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void rna_KeyingSet_paths_clear(KeyingSet *keyingset, ReportList *reports)
|
|
|
|
|
{
|
|
|
|
|
/* if data is valid, call the API function for this */
|
|
|
|
|
if (keyingset) {
|
|
|
|
|
KS_Path *ksp, *kspn;
|
|
|
|
|
|
|
|
|
|
/* free each path as we go to avoid looping twice */
|
2012-03-05 23:30:41 +00:00
|
|
|
for (ksp = keyingset->paths.first; ksp; ksp = kspn) {
|
|
|
|
|
kspn = ksp->next;
|
2010-04-04 17:42:40 +00:00
|
|
|
BKE_keyingset_free_path(keyingset, ksp);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* reset the active path, since there aren't any left */
|
|
|
|
|
keyingset->active_path = 0;
|
|
|
|
|
}
|
|
|
|
|
else {
|
2012-10-21 14:02:30 +00:00
|
|
|
BKE_report(reports, RPT_ERROR, "Keying set paths could not be removed");
|
2010-04-04 17:42:40 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-12 01:17:13 +00:00
|
|
|
/* needs wrapper function to push notifier */
|
|
|
|
|
static NlaTrack *rna_NlaTrack_new(AnimData *adt, bContext *C, NlaTrack *track)
|
|
|
|
|
{
|
|
|
|
|
NlaTrack *new_track = add_nlatrack(adt, track);
|
|
|
|
|
|
2012-05-12 11:01:29 +00:00
|
|
|
WM_event_add_notifier(C, NC_ANIMATION | ND_NLA | NA_ADDED, NULL);
|
2011-01-12 01:17:13 +00:00
|
|
|
|
|
|
|
|
return new_track;
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-02 09:41:26 +00:00
|
|
|
static void rna_NlaTrack_remove(AnimData *adt, bContext *C, ReportList *reports, PointerRNA *track_ptr)
|
2011-01-12 01:17:13 +00:00
|
|
|
{
|
2012-11-02 09:41:26 +00:00
|
|
|
NlaTrack *track = track_ptr->data;
|
|
|
|
|
|
|
|
|
|
if (BLI_findindex(&adt->nla_tracks, track) == -1) {
|
2012-11-07 14:56:53 +00:00
|
|
|
BKE_reportf(reports, RPT_ERROR, "NlaTrack '%s' cannot be removed", track->name);
|
2012-11-02 09:41:26 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-12 01:17:13 +00:00
|
|
|
free_nlatrack(&adt->nla_tracks, track);
|
2012-11-02 09:41:26 +00:00
|
|
|
RNA_POINTER_INVALIDATE(track_ptr);
|
2011-01-12 01:17:13 +00:00
|
|
|
|
2012-05-12 11:01:29 +00:00
|
|
|
WM_event_add_notifier(C, NC_ANIMATION | ND_NLA | NA_REMOVED, NULL);
|
2011-01-12 01:17:13 +00:00
|
|
|
}
|
|
|
|
|
|
2011-01-12 07:16:24 +00:00
|
|
|
static PointerRNA rna_NlaTrack_active_get(PointerRNA *ptr)
|
2011-01-12 01:17:13 +00:00
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
AnimData *adt = (AnimData *)ptr->data;
|
2012-03-05 23:30:41 +00:00
|
|
|
NlaTrack *track = BKE_nlatrack_find_active(&adt->nla_tracks);
|
2011-01-12 07:16:24 +00:00
|
|
|
return rna_pointer_inherit_refine(ptr, &RNA_NlaTrack, track);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void rna_NlaTrack_active_set(PointerRNA *ptr, PointerRNA value)
|
|
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
AnimData *adt = (AnimData *)ptr->data;
|
|
|
|
|
NlaTrack *track = (NlaTrack *)value.data;
|
2011-01-12 07:16:24 +00:00
|
|
|
BKE_nlatrack_set_active(&adt->nla_tracks, track);
|
2011-01-12 01:17:13 +00:00
|
|
|
}
|
2010-04-04 17:42:40 +00:00
|
|
|
|
2011-04-26 13:49:40 +00:00
|
|
|
|
|
|
|
|
static FCurve *rna_Driver_from_existing(AnimData *adt, bContext *C, FCurve *src_driver)
|
|
|
|
|
{
|
|
|
|
|
/* verify that we've got a driver to duplicate */
|
|
|
|
|
if (ELEM(NULL, src_driver, src_driver->driver)) {
|
2012-10-21 14:02:30 +00:00
|
|
|
BKE_report(CTX_wm_reports(C), RPT_ERROR, "No valid driver data to create copy of");
|
2011-04-26 13:49:40 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* just make a copy of the existing one and add to self */
|
|
|
|
|
FCurve *new_fcu = copy_fcurve(src_driver);
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
/* XXX: if we impose any ordering on these someday, this will be problematic */
|
2011-04-26 13:49:40 +00:00
|
|
|
BLI_addtail(&adt->drivers, new_fcu);
|
|
|
|
|
return new_fcu;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
#else
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* helper function for Keying Set -> keying settings */
|
2012-06-29 09:16:59 +00:00
|
|
|
/* TODO: use reg option! */
|
|
|
|
|
static void rna_def_common_keying_flags(StructRNA *srna, short UNUSED(reg))
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
{
|
|
|
|
|
PropertyRNA *prop;
|
2010-09-23 08:15:53 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_options", PROP_ENUM, PROP_NONE);
|
2010-09-23 08:15:53 +00:00
|
|
|
RNA_def_property_enum_sdna(prop, NULL, "keyingflag");
|
|
|
|
|
RNA_def_property_enum_items(prop, keying_flag_items);
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL | PROP_ENUM_FLAG);
|
2010-09-23 08:15:53 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Options", "Keying set options");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* --- */
|
|
|
|
|
|
2012-03-08 14:04:06 +00:00
|
|
|
/* To avoid repeating it twice! */
|
2012-05-12 11:01:29 +00:00
|
|
|
#define KEYINGSET_IDNAME_DOC \
|
|
|
|
|
"If this is set, the Keying Set gets a custom ID, otherwise it takes " \
|
|
|
|
|
"the name of the class used to define the Keying Set (for example, " \
|
|
|
|
|
"if the class name is \"BUILTIN_KSI_location\", and bl_idname is not " \
|
|
|
|
|
"set by the script, then bl_idname = \"BUILTIN_KSI_location\")"
|
2012-03-08 14:04:06 +00:00
|
|
|
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
static void rna_def_keyingset_info(BlenderRNA *brna)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
PropertyRNA *parm;
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "KeyingSetInfo", NULL);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_struct_sdna(srna, "KeyingSetInfo");
|
2010-03-25 11:34:18 +00:00
|
|
|
RNA_def_struct_ui_text(srna, "Keying Set Info", "Callback function defines for builtin Keying Sets");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_struct_refine_func(srna, "rna_KeyingSetInfo_refine");
|
2011-05-18 11:21:10 +00:00
|
|
|
RNA_def_struct_register_funcs(srna, "rna_KeyingSetInfo_register", "rna_KeyingSetInfo_unregister", NULL);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
/* Properties --------------------- */
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
RNA_define_verify_sdna(0); /* not in sdna */
|
2012-03-08 14:04:06 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_idname", PROP_STRING, PROP_NONE);
|
2010-03-24 12:48:03 +00:00
|
|
|
RNA_def_property_string_sdna(prop, NULL, "idname");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER | PROP_NEVER_CLAMP);
|
2012-03-08 14:04:06 +00:00
|
|
|
RNA_def_property_ui_text(prop, "ID Name", KEYINGSET_IDNAME_DOC);
|
|
|
|
|
|
|
|
|
|
prop = RNA_def_property(srna, "bl_label", PROP_STRING, PROP_NONE);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_property_string_sdna(prop, NULL, "name");
|
2012-03-08 14:04:06 +00:00
|
|
|
RNA_def_property_ui_text(prop, "UI Name", "");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_struct_name_property(srna, prop);
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER);
|
|
|
|
|
|
2013-01-05 13:52:41 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_description", PROP_STRING, PROP_NONE);
|
2012-03-08 14:04:06 +00:00
|
|
|
RNA_def_property_string_sdna(prop, NULL, "description");
|
|
|
|
|
RNA_def_property_string_maxlength(prop, RNA_DYN_DESCR_MAX); /* else it uses the pointer size! */
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
|
|
|
|
RNA_def_property_ui_text(prop, "Description", "A short description of the keying set");
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
rna_def_common_keying_flags(srna, 1); /* '1' arg here is to indicate that we need these to be set on registering */
|
|
|
|
|
|
|
|
|
|
RNA_define_verify_sdna(1);
|
|
|
|
|
|
|
|
|
|
/* Function Callbacks ------------- */
|
2012-05-12 11:01:29 +00:00
|
|
|
/* poll */
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "poll", NULL);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_function_ui_description(func, "Test if Keying Set can be used or not");
|
|
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER);
|
|
|
|
|
RNA_def_function_return(func, RNA_def_boolean(func, "ok", 1, "", ""));
|
2012-03-05 23:30:41 +00:00
|
|
|
parm = RNA_def_pointer(func, "context", "Context", "", "");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED);
|
|
|
|
|
|
2012-05-12 11:01:29 +00:00
|
|
|
/* iterator */
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "iterator", NULL);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_function_ui_description(func, "Call generate() on the structs which have properties to be keyframed");
|
|
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER);
|
2012-03-05 23:30:41 +00:00
|
|
|
parm = RNA_def_pointer(func, "context", "Context", "", "");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED);
|
2012-03-05 23:30:41 +00:00
|
|
|
parm = RNA_def_pointer(func, "ks", "KeyingSet", "", "");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED);
|
|
|
|
|
|
2012-05-12 11:01:29 +00:00
|
|
|
/* generate */
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "generate", NULL);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_function_ui_description(func, "Add Paths to the Keying Set to keyframe the properties of the given data");
|
|
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER);
|
2012-03-05 23:30:41 +00:00
|
|
|
parm = RNA_def_pointer(func, "context", "Context", "", "");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED);
|
2012-03-05 23:30:41 +00:00
|
|
|
parm = RNA_def_pointer(func, "ks", "KeyingSet", "", "");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED);
|
2012-03-18 09:27:36 +00:00
|
|
|
parm = RNA_def_pointer(func, "data", "AnyType", "", "");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED | PROP_RNAPTR | PROP_NEVER_NULL);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
}
|
2009-02-13 01:51:33 +00:00
|
|
|
|
2009-09-14 16:52:06 +00:00
|
|
|
static void rna_def_keyingset_path(BlenderRNA *brna)
|
2009-02-13 01:51:33 +00:00
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "KeyingSetPath", NULL);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_struct_sdna(srna, "KS_Path");
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_struct_ui_text(srna, "Keying Set Path", "Path to a setting for use in a Keying Set");
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
/* ID */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "id", PROP_POINTER, PROP_NONE);
|
2009-10-14 09:08:53 +00:00
|
|
|
RNA_def_property_struct_type(prop, "ID");
|
|
|
|
|
RNA_def_property_flag(prop, PROP_EDITABLE);
|
|
|
|
|
RNA_def_property_editable_func(prop, "rna_ksPath_id_editable");
|
2010-08-03 05:14:59 +00:00
|
|
|
RNA_def_property_pointer_funcs(prop, NULL, NULL, "rna_ksPath_id_typef", NULL);
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_ui_text(prop, "ID-Block",
|
|
|
|
|
"ID-Block that keyframes for Keying Set should be added to "
|
|
|
|
|
"(for Absolute Keying Sets only)");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_EDITED, NULL); /* XXX: maybe a bit too noisy */
|
2009-02-13 01:51:33 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "id_type", PROP_ENUM, PROP_NONE);
|
2009-10-14 09:08:53 +00:00
|
|
|
RNA_def_property_enum_sdna(prop, NULL, "idtype");
|
|
|
|
|
RNA_def_property_enum_items(prop, id_type_items);
|
|
|
|
|
RNA_def_property_enum_default(prop, ID_OB);
|
2009-11-13 01:04:01 +00:00
|
|
|
RNA_def_property_enum_funcs(prop, NULL, "rna_ksPath_id_type_set", NULL);
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "ID Type", "Type of ID-block that can be used");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_EDITED, NULL); /* XXX: maybe a bit too noisy */
|
2009-10-14 09:08:53 +00:00
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
/* Group */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "group", PROP_STRING, PROP_NONE);
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Group Name", "Name of Action Group to assign setting(s) for this path to");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_EDITED, NULL); /* XXX: maybe a bit too noisy */
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
/* Grouping */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "group_method", PROP_ENUM, PROP_NONE);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_property_enum_sdna(prop, NULL, "groupmode");
|
2009-08-25 04:05:37 +00:00
|
|
|
RNA_def_property_enum_items(prop, keyingset_path_grouping_items);
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Grouping Method", "Method used to define which Group-name to use");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_EDITED, NULL); /* XXX: maybe a bit too noisy */
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
/* Path + Array Index */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "data_path", PROP_STRING, PROP_NONE);
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_string_funcs(prop, "rna_ksPath_RnaPath_get", "rna_ksPath_RnaPath_length",
|
|
|
|
|
"rna_ksPath_RnaPath_set");
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Data Path", "Path to property setting");
|
2012-03-05 23:30:41 +00:00
|
|
|
RNA_def_struct_name_property(srna, prop); /* XXX this is the best indicator for now... */
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_EDITED, NULL);
|
2011-03-13 06:44:40 +00:00
|
|
|
|
|
|
|
|
/* called 'index' when given as function arg */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "array_index", PROP_INT, PROP_NONE);
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "RNA Array Index", "Index to the specific setting if applicable");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_EDITED, NULL); /* XXX: maybe a bit too noisy */
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
/* Flags */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "use_entire_array", PROP_BOOLEAN, PROP_NONE);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "flag", KSP_FLAG_WHOLE_ARRAY);
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Entire Array",
|
|
|
|
|
"When an 'array/vector' type is chosen (Location, Rotation, Color, etc.), "
|
|
|
|
|
"entire array is to be used");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_EDITED, NULL); /* XXX: maybe a bit too noisy */
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
|
/* Keyframing Settings */
|
|
|
|
|
rna_def_common_keying_flags(srna, 0);
|
2009-02-13 01:51:33 +00:00
|
|
|
}
|
|
|
|
|
|
2010-04-04 17:42:40 +00:00
|
|
|
|
|
|
|
|
/* keyingset.paths */
|
|
|
|
|
static void rna_def_keyingset_paths(BlenderRNA *brna, PropertyRNA *cprop)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
PropertyRNA *parm;
|
2010-08-23 22:16:45 +00:00
|
|
|
|
|
|
|
|
PropertyRNA *prop;
|
2010-04-04 17:42:40 +00:00
|
|
|
|
|
|
|
|
RNA_def_property_srna(cprop, "KeyingSetPaths");
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "KeyingSetPaths", NULL);
|
2010-04-04 17:42:40 +00:00
|
|
|
RNA_def_struct_sdna(srna, "KeyingSet");
|
|
|
|
|
RNA_def_struct_ui_text(srna, "Keying set paths", "Collection of keying set paths");
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Add Path */
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "add", "rna_KeyingSet_paths_add");
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_function_ui_description(func, "Add a new path for the Keying Set");
|
2010-04-04 17:42:40 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_USE_REPORTS);
|
2012-05-12 11:01:29 +00:00
|
|
|
/* return arg */
|
2012-03-05 23:30:41 +00:00
|
|
|
parm = RNA_def_pointer(func, "ksp", "KeyingSetPath", "New Path", "Path created and added to the Keying Set");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_function_return(func, parm);
|
|
|
|
|
/* ID-block for target */
|
2012-03-18 09:27:36 +00:00
|
|
|
parm = RNA_def_pointer(func, "target_id", "ID", "Target ID", "ID-Datablock for the destination");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED);
|
|
|
|
|
/* rna-path */
|
|
|
|
|
/* XXX hopefully this is long enough */
|
2012-03-18 09:27:36 +00:00
|
|
|
parm = RNA_def_string(func, "data_path", "", 256, "Data-Path", "RNA-Path to destination property");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED);
|
|
|
|
|
/* index (defaults to -1 for entire array) */
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_int(func, "index", -1, -1, INT_MAX, "Index",
|
|
|
|
|
"The index of the destination property (i.e. axis of Location/Rotation/etc.), "
|
|
|
|
|
"or -1 for the entire array", 0, INT_MAX);
|
2012-05-12 11:01:29 +00:00
|
|
|
/* grouping */
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_enum(func, "group_method", keyingset_path_grouping_items, KSP_GROUP_KSNAME,
|
|
|
|
|
"Grouping Method", "Method used to define which Group-name to use");
|
|
|
|
|
RNA_def_string(func, "group_name", "", 64, "Group Name",
|
|
|
|
|
"Name of Action Group to assign destination to (only if grouping mode is to use this name)");
|
2010-04-04 17:42:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Remove Path */
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "remove", "rna_KeyingSet_paths_remove");
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_function_ui_description(func, "Remove the given path from the Keying Set");
|
2010-04-04 17:42:40 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_USE_REPORTS);
|
2012-05-12 11:01:29 +00:00
|
|
|
/* path to remove */
|
2012-03-18 09:27:36 +00:00
|
|
|
parm = RNA_def_pointer(func, "path", "KeyingSetPath", "Path", "");
|
2012-11-02 09:41:26 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED | PROP_NEVER_NULL | PROP_RNAPTR);
|
|
|
|
|
RNA_def_property_clear_flag(parm, PROP_THICK_WRAP);
|
2010-04-04 17:42:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Remove All Paths */
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "clear", "rna_KeyingSet_paths_clear");
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_function_ui_description(func, "Remove all the paths from the Keying Set");
|
2010-04-04 17:42:40 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_USE_REPORTS);
|
2010-08-23 22:16:45 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "active", PROP_POINTER, PROP_NONE);
|
2010-08-23 22:16:45 +00:00
|
|
|
RNA_def_property_struct_type(prop, "KeyingSetPath");
|
|
|
|
|
RNA_def_property_flag(prop, PROP_EDITABLE);
|
|
|
|
|
RNA_def_property_editable_func(prop, "rna_KeyingSet_active_ksPath_editable");
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_pointer_funcs(prop, "rna_KeyingSet_active_ksPath_get",
|
|
|
|
|
"rna_KeyingSet_active_ksPath_set", NULL, NULL);
|
2010-08-23 22:16:45 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Active Keying Set", "Active Keying Set used to insert/delete keyframes");
|
2010-08-24 04:02:50 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "active_index", PROP_INT, PROP_NONE);
|
2010-08-24 04:02:50 +00:00
|
|
|
RNA_def_property_int_sdna(prop, NULL, "active_path");
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_int_funcs(prop, "rna_KeyingSet_active_ksPath_index_get", "rna_KeyingSet_active_ksPath_index_set",
|
|
|
|
|
"rna_KeyingSet_active_ksPath_index_range");
|
2010-08-24 04:02:50 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Active Path Index", "Current Keying Set index");
|
2010-04-04 17:42:40 +00:00
|
|
|
}
|
|
|
|
|
|
2009-09-14 16:52:06 +00:00
|
|
|
static void rna_def_keyingset(BlenderRNA *brna)
|
2009-02-13 01:51:33 +00:00
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "KeyingSet", NULL);
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_struct_ui_text(srna, "Keying Set", "Settings that should be keyframed together");
|
2009-02-13 01:51:33 +00:00
|
|
|
|
2012-11-06 05:04:54 +00:00
|
|
|
/* Id/Label */
|
2012-03-08 14:04:06 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_idname", PROP_STRING, PROP_NONE);
|
|
|
|
|
RNA_def_property_string_sdna(prop, NULL, "idname");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER | PROP_NEVER_CLAMP);
|
2012-03-08 14:04:06 +00:00
|
|
|
RNA_def_property_ui_text(prop, "ID Name", KEYINGSET_IDNAME_DOC);
|
2012-11-06 05:04:54 +00:00
|
|
|
/* RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_RENAME, NULL); */ /* NOTE: disabled, as ID name shouldn't be editable */
|
2012-03-08 14:04:06 +00:00
|
|
|
|
|
|
|
|
prop = RNA_def_property(srna, "bl_label", PROP_STRING, PROP_NONE);
|
|
|
|
|
RNA_def_property_string_sdna(prop, NULL, "name");
|
2012-11-06 05:04:54 +00:00
|
|
|
RNA_def_property_string_funcs(prop, NULL, NULL, "rna_KeyingSet_name_set");
|
2012-03-08 14:04:06 +00:00
|
|
|
RNA_def_property_ui_text(prop, "UI Name", "");
|
2011-07-01 02:37:44 +00:00
|
|
|
RNA_def_struct_ui_icon(srna, ICON_KEYINGSET);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_struct_name_property(srna, prop);
|
2012-11-06 05:04:54 +00:00
|
|
|
RNA_def_property_update(prop, NC_SCENE | ND_KEYINGSET | NA_RENAME, NULL);
|
2012-03-08 14:04:06 +00:00
|
|
|
|
2013-01-05 13:52:41 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_description", PROP_STRING, PROP_NONE);
|
2012-03-08 14:04:06 +00:00
|
|
|
RNA_def_property_string_sdna(prop, NULL, "description");
|
|
|
|
|
RNA_def_property_string_maxlength(prop, RNA_DYN_DESCR_MAX); /* else it uses the pointer size! */
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
|
|
|
|
RNA_def_property_ui_text(prop, "Description", "A short description of the keying set");
|
2009-02-13 01:51:33 +00:00
|
|
|
|
2010-03-25 11:34:18 +00:00
|
|
|
/* KeyingSetInfo (Type Info) for Builtin Sets only */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "type_info", PROP_POINTER, PROP_NONE);
|
2010-03-25 11:34:18 +00:00
|
|
|
RNA_def_property_struct_type(prop, "KeyingSetInfo");
|
2010-08-03 05:14:59 +00:00
|
|
|
RNA_def_property_pointer_funcs(prop, "rna_KeyingSet_typeinfo_get", NULL, NULL, NULL);
|
2010-05-04 05:15:53 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Type Info", "Callback function defines for built-in Keying Sets");
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
/* Paths */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "paths", PROP_COLLECTION, PROP_NONE);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_property_collection_sdna(prop, NULL, "paths", NULL);
|
|
|
|
|
RNA_def_property_struct_type(prop, "KeyingSetPath");
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Paths", "Keying Set Paths to define settings that get keyframed together");
|
2010-04-04 17:42:40 +00:00
|
|
|
rna_def_keyingset_paths(brna, prop);
|
2010-08-24 04:02:50 +00:00
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
/* Flags */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "is_path_absolute", PROP_BOOLEAN, PROP_NONE);
|
2010-08-18 07:14:10 +00:00
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "flag", KEYINGSET_ABSOLUTE);
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Absolute",
|
|
|
|
|
"Keying Set defines specific paths/settings to be keyframed "
|
|
|
|
|
"(i.e. is not reliant on context info)");
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
/* Keyframing Flags */
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
rna_def_common_keying_flags(srna, 0);
|
2009-02-13 01:51:33 +00:00
|
|
|
|
2009-12-10 10:40:28 +00:00
|
|
|
|
2009-08-25 04:05:37 +00:00
|
|
|
/* Keying Set API */
|
|
|
|
|
RNA_api_keyingset(srna);
|
2009-02-13 01:51:33 +00:00
|
|
|
}
|
|
|
|
|
|
2012-03-08 14:04:06 +00:00
|
|
|
#undef KEYINGSET_IDNAME_DOC
|
2009-02-13 01:51:33 +00:00
|
|
|
/* --- */
|
|
|
|
|
|
2011-01-12 01:17:13 +00:00
|
|
|
static void rna_api_animdata_nla_tracks(BlenderRNA *brna, PropertyRNA *cprop)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *parm;
|
|
|
|
|
FunctionRNA *func;
|
2011-01-12 07:16:24 +00:00
|
|
|
|
|
|
|
|
PropertyRNA *prop;
|
2011-01-12 01:17:13 +00:00
|
|
|
|
|
|
|
|
RNA_def_property_srna(cprop, "NlaTracks");
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "NlaTracks", NULL);
|
2011-01-12 01:17:13 +00:00
|
|
|
RNA_def_struct_sdna(srna, "AnimData");
|
|
|
|
|
RNA_def_struct_ui_text(srna, "NLA Tracks", "Collection of NLA Tracks");
|
|
|
|
|
|
|
|
|
|
func = RNA_def_function(srna, "new", "rna_NlaTrack_new");
|
|
|
|
|
RNA_def_function_flag(func, FUNC_USE_CONTEXT);
|
2011-04-26 13:49:40 +00:00
|
|
|
RNA_def_function_ui_description(func, "Add a new NLA Track");
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_pointer(func, "prev", "NlaTrack", "", "NLA Track to add the new one after");
|
2011-01-12 01:17:13 +00:00
|
|
|
/* return type */
|
2011-09-19 13:23:58 +00:00
|
|
|
parm = RNA_def_pointer(func, "track", "NlaTrack", "", "New NLA Track");
|
2011-01-12 01:17:13 +00:00
|
|
|
RNA_def_function_return(func, parm);
|
|
|
|
|
|
|
|
|
|
func = RNA_def_function(srna, "remove", "rna_NlaTrack_remove");
|
2012-11-02 09:41:26 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_USE_REPORTS | FUNC_USE_CONTEXT);
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_function_ui_description(func, "Remove a NLA Track");
|
|
|
|
|
parm = RNA_def_pointer(func, "track", "NlaTrack", "", "NLA Track to remove");
|
2012-11-02 09:41:26 +00:00
|
|
|
RNA_def_property_flag(parm, PROP_REQUIRED | PROP_NEVER_NULL | PROP_RNAPTR);
|
|
|
|
|
RNA_def_property_clear_flag(parm, PROP_THICK_WRAP);
|
2011-01-12 07:16:24 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "active", PROP_POINTER, PROP_NONE);
|
2011-01-12 07:16:24 +00:00
|
|
|
RNA_def_property_struct_type(prop, "NlaTrack");
|
|
|
|
|
RNA_def_property_pointer_funcs(prop, "rna_NlaTrack_active_get", "rna_NlaTrack_active_set", NULL, NULL);
|
|
|
|
|
RNA_def_property_flag(prop, PROP_EDITABLE);
|
|
|
|
|
RNA_def_property_ui_text(prop, "Active Constraint", "Active Object constraint");
|
|
|
|
|
/* XXX: should (but doesn't) update the active track in the NLA window */
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_ANIMATION | ND_NLA | NA_SELECTED, NULL);
|
2011-01-12 01:17:13 +00:00
|
|
|
}
|
|
|
|
|
|
2011-04-26 13:49:40 +00:00
|
|
|
static void rna_api_animdata_drivers(BlenderRNA *brna, PropertyRNA *cprop)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *parm;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
/* PropertyRNA *prop; */
|
2011-04-26 13:49:40 +00:00
|
|
|
|
|
|
|
|
RNA_def_property_srna(cprop, "AnimDataDrivers");
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "AnimDataDrivers", NULL);
|
2011-04-26 13:49:40 +00:00
|
|
|
RNA_def_struct_sdna(srna, "AnimData");
|
|
|
|
|
RNA_def_struct_ui_text(srna, "Drivers", "Collection of Driver F-Curves");
|
|
|
|
|
|
|
|
|
|
func = RNA_def_function(srna, "from_existing", "rna_Driver_from_existing");
|
|
|
|
|
RNA_def_function_flag(func, FUNC_USE_CONTEXT);
|
|
|
|
|
RNA_def_function_ui_description(func, "Add a new driver given an existing one");
|
|
|
|
|
RNA_def_pointer(func, "src_driver", "FCurve", "", "Existing Driver F-Curve to use as template for a new one");
|
|
|
|
|
/* return type */
|
2011-09-19 13:23:58 +00:00
|
|
|
parm = RNA_def_pointer(func, "driver", "FCurve", "", "New Driver F-Curve");
|
2011-04-26 13:49:40 +00:00
|
|
|
RNA_def_function_return(func, parm);
|
|
|
|
|
}
|
|
|
|
|
|
2009-02-13 01:51:33 +00:00
|
|
|
void rna_def_animdata_common(StructRNA *srna)
|
|
|
|
|
{
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "animation_data", PROP_POINTER, PROP_NONE);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_property_pointer_sdna(prop, NULL, "adt");
|
2009-03-23 13:24:48 +00:00
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Animation Data", "Animation data for this datablock");
|
2009-02-13 01:51:33 +00:00
|
|
|
}
|
|
|
|
|
|
2012-09-23 05:02:06 +00:00
|
|
|
static void rna_def_animdata(BlenderRNA *brna)
|
2009-02-13 01:51:33 +00:00
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "AnimData", NULL);
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_struct_ui_text(srna, "Animation Data", "Animation data for datablock");
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
/* NLA */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "nla_tracks", PROP_COLLECTION, PROP_NONE);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_property_collection_sdna(prop, NULL, "nla_tracks", NULL);
|
2009-06-07 06:49:04 +00:00
|
|
|
RNA_def_property_struct_type(prop, "NlaTrack");
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "NLA Tracks", "NLA Tracks (i.e. Animation Layers)");
|
2011-01-12 01:17:13 +00:00
|
|
|
|
|
|
|
|
rna_api_animdata_nla_tracks(brna, prop);
|
2009-02-13 01:51:33 +00:00
|
|
|
|
2009-07-31 07:43:47 +00:00
|
|
|
/* Active Action */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "action", PROP_POINTER, PROP_NONE);
|
2012-05-12 11:01:29 +00:00
|
|
|
/* this flag as well as the dynamic test must be defined for this to be editable... */
|
|
|
|
|
RNA_def_property_flag(prop, PROP_EDITABLE | PROP_ID_REFCOUNT);
|
2011-04-26 13:49:40 +00:00
|
|
|
RNA_def_property_pointer_funcs(prop, NULL, "rna_AnimData_action_set", NULL, "rna_Action_id_poll");
|
2009-08-02 13:15:20 +00:00
|
|
|
RNA_def_property_editable_func(prop, "rna_AnimData_action_editable");
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Action", "Active Action for this datablock");
|
2011-01-19 10:54:34 +00:00
|
|
|
RNA_def_property_update(prop, NC_ANIMATION, NULL); /* this will do? */
|
2.5 - Assorted Animation UI/Editing Tweaks
Main Feature:
* It is now possible to choose which AnimData block is the 'active' one for editing, and/or select them too. AnimData blocks are generally the dark blue and lighter-blue expanders (i.e. Scene, Object, Camera, Lamp, Curve, Armature, etc.)
* Objects are no longer selected/deselected when AKEY is used to toggle selection of channels. This was getting a bit annoying.
* Following on from selection of AnimData blocks, it is now possible to select/make active an AnimData block in the animation editors, and change the active action for that block via the 'Animation Data' panel in NLA Editor's properties region.
--> Be aware that user-counts are not totally handled correctly there yet, so some funky behaviour might be seen...
--> It is possible to assign a new action, or to assign an existing one, allowing to switch between actions as in the past with Actions/IPO Editors...
Other tweaks:
* Some code tweaks towards making the 'Euler Filter' feature for Graph Editor working sometime soon
* Added some backend code for snapping the values of keyframes to a single value. Still need to work out some UI for it though.
* Shuffled the code for ACT_OT_new() around, and removed the poll() callback so that it worked in NLA too.
* Fixed some more notifier bugs with deleting bones and a few other editmode operations for Armatures.
2009-09-27 04:22:04 +00:00
|
|
|
|
2009-07-31 07:43:47 +00:00
|
|
|
/* Active Action Settings */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "action_extrapolation", PROP_ENUM, PROP_NONE);
|
2009-07-31 07:43:47 +00:00
|
|
|
RNA_def_property_enum_sdna(prop, NULL, "act_extendmode");
|
|
|
|
|
RNA_def_property_enum_items(prop, nla_mode_extend_items);
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Action Extrapolation",
|
|
|
|
|
"Action to take for gaps past the Active Action's range (when evaluating with NLA)");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_ANIMATION | ND_NLA, NULL); /* this will do? */
|
2009-07-31 07:43:47 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "action_blend_type", PROP_ENUM, PROP_NONE);
|
2009-07-31 07:43:47 +00:00
|
|
|
RNA_def_property_enum_sdna(prop, NULL, "act_blendmode");
|
|
|
|
|
RNA_def_property_enum_items(prop, nla_mode_blend_items);
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Action Blending",
|
|
|
|
|
"Method used for combining Active Action's result with result of NLA stack");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_ANIMATION | ND_NLA, NULL); /* this will do? */
|
2009-07-31 07:43:47 +00:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "action_influence", PROP_FLOAT, PROP_NONE);
|
2009-07-31 07:43:47 +00:00
|
|
|
RNA_def_property_float_sdna(prop, NULL, "act_influence");
|
|
|
|
|
RNA_def_property_float_default(prop, 1.0f);
|
|
|
|
|
RNA_def_property_range(prop, 0.0f, 1.0f);
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Action Influence",
|
|
|
|
|
"Amount the Active Action contributes to the result of the NLA stack");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_ANIMATION | ND_NLA, NULL); /* this will do? */
|
2009-02-13 01:51:33 +00:00
|
|
|
|
|
|
|
|
/* Drivers */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "drivers", PROP_COLLECTION, PROP_NONE);
|
2009-02-13 01:51:33 +00:00
|
|
|
RNA_def_property_collection_sdna(prop, NULL, "drivers", NULL);
|
|
|
|
|
RNA_def_property_struct_type(prop, "FCurve");
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "Drivers", "The Drivers/Expressions for this datablock");
|
2009-02-13 01:51:33 +00:00
|
|
|
|
2011-04-26 13:49:40 +00:00
|
|
|
rna_api_animdata_drivers(brna, prop);
|
|
|
|
|
|
2009-07-31 07:43:47 +00:00
|
|
|
/* General Settings */
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "use_nla", PROP_BOOLEAN, PROP_NONE);
|
2009-07-31 07:43:47 +00:00
|
|
|
RNA_def_property_boolean_negative_sdna(prop, NULL, "flag", ADT_NLA_EVAL_OFF);
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_property_ui_text(prop, "NLA Evaluation Enabled", "NLA stack is evaluated when evaluating this block");
|
2012-05-12 11:01:29 +00:00
|
|
|
RNA_def_property_update(prop, NC_ANIMATION | ND_NLA, NULL); /* this will do? */
|
2009-02-13 01:51:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* --- */
|
|
|
|
|
|
|
|
|
|
void RNA_def_animation(BlenderRNA *brna)
|
|
|
|
|
{
|
|
|
|
|
rna_def_animdata(brna);
|
|
|
|
|
|
|
|
|
|
rna_def_keyingset(brna);
|
|
|
|
|
rna_def_keyingset_path(brna);
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
rna_def_keyingset_info(brna);
|
2009-02-13 01:51:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif
|