2009-07-02 05:25:14 +00:00
|
|
|
/**
|
|
|
|
|
* $Id$
|
|
|
|
|
*
|
|
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2009-07-02 05:25:14 +00:00
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2009 Blender Foundation, Joshua Leung
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is: all of this file.
|
|
|
|
|
*
|
|
|
|
|
* Contributor(s): Joshua Leung (full recode)
|
|
|
|
|
*
|
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
2009-04-13 02:40:56 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#include <math.h>
|
|
|
|
|
#include <float.h>
|
|
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
|
|
#include "BLI_blenlib.h"
|
2009-11-10 20:43:45 +00:00
|
|
|
#include "BLI_math.h"
|
2009-04-13 02:40:56 +00:00
|
|
|
#include "BLI_dynstr.h"
|
|
|
|
|
|
|
|
|
|
#include "DNA_anim_types.h"
|
|
|
|
|
#include "DNA_constraint_types.h"
|
|
|
|
|
#include "DNA_scene_types.h"
|
|
|
|
|
|
|
|
|
|
#include "BKE_animsys.h"
|
|
|
|
|
#include "BKE_action.h"
|
2010-03-25 11:34:18 +00:00
|
|
|
#include "BKE_context.h"
|
2009-04-13 02:40:56 +00:00
|
|
|
#include "BKE_constraint.h"
|
2009-11-24 12:35:06 +00:00
|
|
|
#include "BKE_depsgraph.h"
|
2009-04-13 02:40:56 +00:00
|
|
|
#include "BKE_fcurve.h"
|
|
|
|
|
#include "BKE_utildefines.h"
|
|
|
|
|
#include "BKE_context.h"
|
|
|
|
|
#include "BKE_report.h"
|
|
|
|
|
#include "BKE_key.h"
|
|
|
|
|
#include "BKE_material.h"
|
|
|
|
|
|
|
|
|
|
#include "ED_keyframing.h"
|
2010-03-25 11:34:18 +00:00
|
|
|
#include "ED_screen.h"
|
2009-04-13 02:40:56 +00:00
|
|
|
|
|
|
|
|
#include "UI_interface.h"
|
|
|
|
|
|
|
|
|
|
#include "WM_api.h"
|
|
|
|
|
#include "WM_types.h"
|
|
|
|
|
|
|
|
|
|
#include "RNA_access.h"
|
|
|
|
|
#include "RNA_define.h"
|
|
|
|
|
|
|
|
|
|
#include "anim_intern.h"
|
|
|
|
|
|
2009-10-03 04:21:38 +00:00
|
|
|
/* ************************************************** */
|
|
|
|
|
/* KEYING SETS - OPERATORS (for use in UI panels) */
|
|
|
|
|
/* These operators are really duplication of existing functionality, but just for completeness,
|
|
|
|
|
* they're here too, and will give the basic data needed...
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* poll callback for adding default KeyingSet */
|
|
|
|
|
static int keyingset_poll_default_add (bContext *C)
|
|
|
|
|
{
|
|
|
|
|
/* as long as there's an active Scene, it's fine */
|
|
|
|
|
return (CTX_data_scene(C) != NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* poll callback for editing active KeyingSet */
|
|
|
|
|
static int keyingset_poll_active_edit (bContext *C)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
|
|
|
|
|
if (scene == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* there must be an active KeyingSet (and KeyingSets) */
|
|
|
|
|
return ((scene->active_keyingset > 0) && (scene->keyingsets.first));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* poll callback for editing active KeyingSet Path */
|
|
|
|
|
static int keyingset_poll_activePath_edit (bContext *C)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
KeyingSet *ks;
|
|
|
|
|
|
|
|
|
|
if (scene == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
if (scene->active_keyingset <= 0)
|
|
|
|
|
return 0;
|
|
|
|
|
else
|
|
|
|
|
ks= BLI_findlink(&scene->keyingsets, scene->active_keyingset-1);
|
|
|
|
|
|
|
|
|
|
/* there must be an active KeyingSet and an active path */
|
|
|
|
|
return ((ks) && (ks->paths.first) && (ks->active_path > 0));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Add a Default (Empty) Keying Set ------------------------- */
|
|
|
|
|
|
|
|
|
|
static int add_default_keyingset_exec (bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
short flag=0, keyingflag=0;
|
|
|
|
|
|
|
|
|
|
/* validate flags
|
|
|
|
|
* - absolute KeyingSets should be created by default
|
|
|
|
|
*/
|
|
|
|
|
flag |= KEYINGSET_ABSOLUTE;
|
|
|
|
|
|
2009-12-14 12:09:20 +00:00
|
|
|
/* 2nd arg is 0 to indicate that we don't want to include autokeying mode related settings */
|
|
|
|
|
keyingflag = ANIM_get_keyframing_flags(scene, 0);
|
|
|
|
|
|
2009-10-03 04:21:38 +00:00
|
|
|
/* call the API func, and set the active keyingset index */
|
|
|
|
|
BKE_keyingset_add(&scene->keyingsets, NULL, flag, keyingflag);
|
|
|
|
|
|
|
|
|
|
scene->active_keyingset= BLI_countlist(&scene->keyingsets);
|
|
|
|
|
|
2009-10-16 10:49:54 +00:00
|
|
|
/* send notifiers */
|
|
|
|
|
WM_event_add_notifier(C, NC_SCENE|ND_KEYINGSET, NULL);
|
|
|
|
|
|
2009-10-03 04:21:38 +00:00
|
|
|
return OPERATOR_FINISHED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ANIM_OT_keying_set_add (wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
|
|
|
|
ot->name= "Add Empty Keying Set";
|
|
|
|
|
ot->idname= "ANIM_OT_keying_set_add";
|
2010-02-10 21:15:44 +00:00
|
|
|
ot->description= "Add a new (empty) Keying Set to the active Scene";
|
2009-10-03 04:21:38 +00:00
|
|
|
|
|
|
|
|
/* callbacks */
|
|
|
|
|
ot->exec= add_default_keyingset_exec;
|
|
|
|
|
ot->poll= keyingset_poll_default_add;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Remove 'Active' Keying Set ------------------------- */
|
|
|
|
|
|
|
|
|
|
static int remove_active_keyingset_exec (bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
KeyingSet *ks;
|
|
|
|
|
|
|
|
|
|
/* verify the Keying Set to use:
|
|
|
|
|
* - use the active one
|
|
|
|
|
* - return error if it doesn't exist
|
|
|
|
|
*/
|
|
|
|
|
if (scene->active_keyingset == 0) {
|
|
|
|
|
BKE_report(op->reports, RPT_ERROR, "No active Keying Set to remove");
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
ks= BLI_findlink(&scene->keyingsets, scene->active_keyingset-1);
|
|
|
|
|
|
|
|
|
|
/* free KeyingSet's data, then remove it from the scene */
|
|
|
|
|
BKE_keyingset_free(ks);
|
|
|
|
|
BLI_freelinkN(&scene->keyingsets, ks);
|
2009-10-09 09:48:04 +00:00
|
|
|
|
|
|
|
|
/* the active one should now be the previously second-to-last one */
|
|
|
|
|
scene->active_keyingset--;
|
2009-10-03 04:21:38 +00:00
|
|
|
|
2009-10-16 10:49:54 +00:00
|
|
|
/* send notifiers */
|
|
|
|
|
WM_event_add_notifier(C, NC_SCENE|ND_KEYINGSET, NULL);
|
|
|
|
|
|
2009-10-03 04:21:38 +00:00
|
|
|
return OPERATOR_FINISHED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ANIM_OT_keying_set_remove (wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
|
|
|
|
ot->name= "Removed Active Keying Set";
|
|
|
|
|
ot->idname= "ANIM_OT_keying_set_remove";
|
2010-02-10 21:15:44 +00:00
|
|
|
ot->description= "Remove the active Keying Set";
|
2009-10-03 04:21:38 +00:00
|
|
|
|
|
|
|
|
/* callbacks */
|
|
|
|
|
ot->exec= remove_active_keyingset_exec;
|
|
|
|
|
ot->poll= keyingset_poll_active_edit;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add Empty Keying Set Path ------------------------- */
|
|
|
|
|
|
|
|
|
|
static int add_empty_ks_path_exec (bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
KeyingSet *ks;
|
|
|
|
|
KS_Path *ksp;
|
|
|
|
|
|
|
|
|
|
/* verify the Keying Set to use:
|
|
|
|
|
* - use the active one
|
|
|
|
|
* - return error if it doesn't exist
|
|
|
|
|
*/
|
|
|
|
|
if (scene->active_keyingset == 0) {
|
|
|
|
|
BKE_report(op->reports, RPT_ERROR, "No active Keying Set to add empty path to");
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
ks= BLI_findlink(&scene->keyingsets, scene->active_keyingset-1);
|
|
|
|
|
|
|
|
|
|
/* don't use the API method for this, since that checks on values... */
|
|
|
|
|
ksp= MEM_callocN(sizeof(KS_Path), "KeyingSetPath Empty");
|
|
|
|
|
BLI_addtail(&ks->paths, ksp);
|
2009-10-14 09:08:53 +00:00
|
|
|
ks->active_path= BLI_countlist(&ks->paths);
|
2009-10-03 04:21:38 +00:00
|
|
|
|
|
|
|
|
ksp->groupmode= KSP_GROUP_KSNAME; // XXX?
|
2010-01-26 10:29:10 +00:00
|
|
|
ksp->idtype= ID_OB;
|
2009-10-03 04:21:38 +00:00
|
|
|
|
|
|
|
|
return OPERATOR_FINISHED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ANIM_OT_keying_set_path_add (wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
|
|
|
|
ot->name= "Add Empty Keying Set Path";
|
|
|
|
|
ot->idname= "ANIM_OT_keying_set_path_add";
|
|
|
|
|
ot->description= "Add empty path to active Keying Set";
|
|
|
|
|
|
|
|
|
|
/* callbacks */
|
|
|
|
|
ot->exec= add_empty_ks_path_exec;
|
|
|
|
|
ot->poll= keyingset_poll_active_edit;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Remove Active Keying Set Path ------------------------- */
|
|
|
|
|
|
|
|
|
|
static int remove_active_ks_path_exec (bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
KeyingSet *ks= BLI_findlink(&scene->keyingsets, scene->active_keyingset-1);
|
|
|
|
|
|
|
|
|
|
/* if there is a KeyingSet, find the nominated path to remove */
|
|
|
|
|
if (ks) {
|
|
|
|
|
KS_Path *ksp= BLI_findlink(&ks->paths, ks->active_path-1);
|
|
|
|
|
|
|
|
|
|
if (ksp) {
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* remove the active path from the KeyingSet */
|
|
|
|
|
BKE_keyingset_free_path(ks, ksp);
|
2009-10-03 04:21:38 +00:00
|
|
|
|
2009-10-09 09:48:04 +00:00
|
|
|
/* the active path should now be the previously second-to-last active one */
|
|
|
|
|
ks->active_path--;
|
2009-10-03 04:21:38 +00:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BKE_report(op->reports, RPT_ERROR, "No active Keying Set Path to remove");
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BKE_report(op->reports, RPT_ERROR, "No active Keying Set to remove a path from");
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return OPERATOR_FINISHED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ANIM_OT_keying_set_path_remove (wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
|
|
|
|
ot->name= "Remove Active Keying Set Path";
|
|
|
|
|
ot->idname= "ANIM_OT_keying_set_path_remove";
|
2010-02-10 21:15:44 +00:00
|
|
|
ot->description= "Remove active Path from active Keying Set";
|
2009-10-03 04:21:38 +00:00
|
|
|
|
|
|
|
|
/* callbacks */
|
|
|
|
|
ot->exec= remove_active_ks_path_exec;
|
|
|
|
|
ot->poll= keyingset_poll_activePath_edit;
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-04 07:26:32 +00:00
|
|
|
/* ************************************************** */
|
|
|
|
|
/* KEYING SETS - OPERATORS (for use in UI menus) */
|
|
|
|
|
|
|
|
|
|
/* Add to KeyingSet Button Operator ------------------------ */
|
|
|
|
|
|
|
|
|
|
static int add_keyingset_button_exec (bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
KeyingSet *ks = NULL;
|
|
|
|
|
PropertyRNA *prop= NULL;
|
|
|
|
|
PointerRNA ptr;
|
|
|
|
|
char *path = NULL;
|
|
|
|
|
short success= 0;
|
|
|
|
|
int index=0, pflag=0;
|
|
|
|
|
int all= RNA_boolean_get(op->ptr, "all");
|
|
|
|
|
|
|
|
|
|
/* verify the Keying Set to use:
|
|
|
|
|
* - use the active one for now (more control over this can be added later)
|
|
|
|
|
* - add a new one if it doesn't exist
|
|
|
|
|
*/
|
|
|
|
|
if (scene->active_keyingset == 0) {
|
|
|
|
|
short flag=0, keyingflag=0;
|
|
|
|
|
|
|
|
|
|
/* validate flags
|
|
|
|
|
* - absolute KeyingSets should be created by default
|
|
|
|
|
*/
|
|
|
|
|
flag |= KEYINGSET_ABSOLUTE;
|
|
|
|
|
|
2010-01-26 10:29:10 +00:00
|
|
|
keyingflag |= ANIM_get_keyframing_flags(scene, 0);
|
|
|
|
|
|
2009-12-14 12:09:20 +00:00
|
|
|
if (IS_AUTOKEY_FLAG(XYZ2RGB))
|
|
|
|
|
keyingflag |= INSERTKEY_XYZ2RGB;
|
2009-09-04 07:26:32 +00:00
|
|
|
|
|
|
|
|
/* call the API func, and set the active keyingset index */
|
|
|
|
|
ks= BKE_keyingset_add(&scene->keyingsets, "ButtonKeyingSet", flag, keyingflag);
|
|
|
|
|
|
|
|
|
|
scene->active_keyingset= BLI_countlist(&scene->keyingsets);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
ks= BLI_findlink(&scene->keyingsets, scene->active_keyingset-1);
|
|
|
|
|
|
|
|
|
|
/* try to add to keyingset using property retrieved from UI */
|
|
|
|
|
memset(&ptr, 0, sizeof(PointerRNA));
|
|
|
|
|
uiAnimContextProperty(C, &ptr, &prop, &index);
|
|
|
|
|
|
|
|
|
|
/* check if property is able to be added */
|
2010-01-28 16:13:12 +00:00
|
|
|
if (ptr.data && prop && RNA_property_animateable(&ptr, prop)) {
|
2009-09-04 07:26:32 +00:00
|
|
|
path= RNA_path_from_ID_to_property(&ptr, prop);
|
|
|
|
|
|
|
|
|
|
if (path) {
|
|
|
|
|
/* set flags */
|
2009-10-08 06:39:45 +00:00
|
|
|
if (all) {
|
2009-09-04 07:26:32 +00:00
|
|
|
pflag |= KSP_FLAG_WHOLE_ARRAY;
|
|
|
|
|
|
2009-10-08 06:39:45 +00:00
|
|
|
/* we need to set the index for this to 0, even though it may break in some cases, this is
|
|
|
|
|
* necessary if we want the entire array for most cases to get included without the user
|
|
|
|
|
* having to worry about where they clicked
|
|
|
|
|
*/
|
|
|
|
|
index= 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-04 07:26:32 +00:00
|
|
|
/* add path to this setting */
|
2010-02-27 02:03:33 +00:00
|
|
|
BKE_keyingset_add_path(ks, ptr.id.data, NULL, path, index, pflag, KSP_GROUP_KSNAME);
|
2009-10-08 11:29:27 +00:00
|
|
|
ks->active_path= BLI_countlist(&ks->paths);
|
2009-09-04 10:41:02 +00:00
|
|
|
success= 1;
|
2009-09-04 07:26:32 +00:00
|
|
|
|
|
|
|
|
/* free the temp path created */
|
|
|
|
|
MEM_freeN(path);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (success) {
|
|
|
|
|
/* send updates */
|
2009-11-24 11:48:16 +00:00
|
|
|
DAG_ids_flush_update(0);
|
2009-09-04 07:26:32 +00:00
|
|
|
|
|
|
|
|
/* for now, only send ND_KEYS for KeyingSets */
|
2009-09-04 10:41:02 +00:00
|
|
|
WM_event_add_notifier(C, NC_SCENE|ND_KEYINGSET, NULL);
|
2009-09-04 07:26:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return (success)? OPERATOR_FINISHED: OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
|
2009-11-28 14:37:21 +00:00
|
|
|
void ANIM_OT_keyingset_button_add (wmOperatorType *ot)
|
2009-09-04 07:26:32 +00:00
|
|
|
{
|
|
|
|
|
/* identifiers */
|
|
|
|
|
ot->name= "Add to Keying Set";
|
2009-11-28 14:37:21 +00:00
|
|
|
ot->idname= "ANIM_OT_keyingset_button_add";
|
2009-09-04 07:26:32 +00:00
|
|
|
|
|
|
|
|
/* callbacks */
|
|
|
|
|
ot->exec= add_keyingset_button_exec;
|
|
|
|
|
//op->poll= ???
|
|
|
|
|
|
|
|
|
|
/* flags */
|
|
|
|
|
ot->flag= OPTYPE_REGISTER|OPTYPE_UNDO;
|
|
|
|
|
|
|
|
|
|
/* properties */
|
|
|
|
|
RNA_def_boolean(ot->srna, "all", 1, "All", "Add all elements of the array to a Keying Set.");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Remove from KeyingSet Button Operator ------------------------ */
|
|
|
|
|
|
|
|
|
|
static int remove_keyingset_button_exec (bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
KeyingSet *ks = NULL;
|
|
|
|
|
PropertyRNA *prop= NULL;
|
|
|
|
|
PointerRNA ptr;
|
|
|
|
|
char *path = NULL;
|
|
|
|
|
short success= 0;
|
|
|
|
|
int index=0;
|
|
|
|
|
|
|
|
|
|
/* verify the Keying Set to use:
|
|
|
|
|
* - use the active one for now (more control over this can be added later)
|
|
|
|
|
* - return error if it doesn't exist
|
|
|
|
|
*/
|
|
|
|
|
if (scene->active_keyingset == 0) {
|
|
|
|
|
BKE_report(op->reports, RPT_ERROR, "No active Keying Set to remove property from");
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
ks= BLI_findlink(&scene->keyingsets, scene->active_keyingset-1);
|
|
|
|
|
|
|
|
|
|
/* try to add to keyingset using property retrieved from UI */
|
|
|
|
|
memset(&ptr, 0, sizeof(PointerRNA));
|
|
|
|
|
uiAnimContextProperty(C, &ptr, &prop, &index);
|
|
|
|
|
|
|
|
|
|
if (ptr.data && prop) {
|
|
|
|
|
path= RNA_path_from_ID_to_property(&ptr, prop);
|
|
|
|
|
|
|
|
|
|
if (path) {
|
|
|
|
|
KS_Path *ksp;
|
|
|
|
|
|
|
|
|
|
/* try to find a path matching this description */
|
2010-02-27 02:03:33 +00:00
|
|
|
ksp= BKE_keyingset_find_path(ks, ptr.id.data, ks->name, path, index, KSP_GROUP_KSNAME);
|
2009-09-04 07:26:32 +00:00
|
|
|
|
|
|
|
|
if (ksp) {
|
|
|
|
|
/* just free it... */
|
|
|
|
|
MEM_freeN(ksp->rna_path);
|
|
|
|
|
BLI_freelinkN(&ks->paths, ksp);
|
|
|
|
|
|
|
|
|
|
success= 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* free temp path used */
|
|
|
|
|
MEM_freeN(path);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if (success) {
|
|
|
|
|
/* send updates */
|
2009-11-24 11:48:16 +00:00
|
|
|
DAG_ids_flush_update(0);
|
2009-09-04 07:26:32 +00:00
|
|
|
|
|
|
|
|
/* for now, only send ND_KEYS for KeyingSets */
|
2009-09-04 10:41:02 +00:00
|
|
|
WM_event_add_notifier(C, NC_SCENE|ND_KEYINGSET, NULL);
|
2009-09-04 07:26:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return (success)? OPERATOR_FINISHED: OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
|
2009-11-28 14:37:21 +00:00
|
|
|
void ANIM_OT_keyingset_button_remove (wmOperatorType *ot)
|
2009-09-04 07:26:32 +00:00
|
|
|
{
|
|
|
|
|
/* identifiers */
|
|
|
|
|
ot->name= "Remove from Keying Set";
|
2009-11-28 14:37:21 +00:00
|
|
|
ot->idname= "ANIM_OT_keyingset_button_remove";
|
2009-09-04 07:26:32 +00:00
|
|
|
|
|
|
|
|
/* callbacks */
|
|
|
|
|
ot->exec= remove_keyingset_button_exec;
|
|
|
|
|
//op->poll= ???
|
|
|
|
|
|
|
|
|
|
/* flags */
|
|
|
|
|
ot->flag= OPTYPE_REGISTER|OPTYPE_UNDO;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-25 11:34:18 +00:00
|
|
|
/* ******************************************* */
|
|
|
|
|
|
|
|
|
|
/* Change Active KeyingSet Operator ------------------------ */
|
|
|
|
|
/* This operator checks if a menu should be shown for choosing the KeyingSet to make the active one */
|
|
|
|
|
|
|
|
|
|
static int keyingset_active_menu_invoke (bContext *C, wmOperator *op, wmEvent *event)
|
|
|
|
|
{
|
|
|
|
|
/* call the menu, which will call this operator again, hence the cancelled */
|
|
|
|
|
ANIM_keying_sets_menu_setup(C, op->type->name, "ANIM_OT_keying_set_active_set");
|
|
|
|
|
return OPERATOR_CANCELLED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int keyingset_active_menu_exec (bContext *C, wmOperator *op)
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
int type= RNA_int_get(op->ptr, "type");
|
|
|
|
|
|
|
|
|
|
/* simply set the scene's active keying set index, unless the type == 0
|
|
|
|
|
* (i.e. which happens if we want the current active to be maintained)
|
|
|
|
|
*/
|
|
|
|
|
if (type)
|
|
|
|
|
scene->active_keyingset= type;
|
|
|
|
|
|
|
|
|
|
/* send notifiers */
|
|
|
|
|
WM_event_add_notifier(C, NC_SCENE|ND_KEYINGSET, NULL);
|
|
|
|
|
|
|
|
|
|
return OPERATOR_FINISHED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ANIM_OT_keying_set_active_set (wmOperatorType *ot)
|
|
|
|
|
{
|
|
|
|
|
/* identifiers */
|
|
|
|
|
ot->name= "Set Active Keying Set";
|
|
|
|
|
ot->idname= "ANIM_OT_keying_set_active_set";
|
|
|
|
|
|
|
|
|
|
/* callbacks */
|
|
|
|
|
ot->invoke= keyingset_active_menu_invoke;
|
|
|
|
|
ot->exec= keyingset_active_menu_exec;
|
|
|
|
|
ot->poll= ED_operator_areaactive;
|
|
|
|
|
|
|
|
|
|
/* flags */
|
|
|
|
|
ot->flag= OPTYPE_REGISTER|OPTYPE_UNDO;
|
|
|
|
|
|
|
|
|
|
/* keyingset to use
|
|
|
|
|
* - here the type is int not enum, since many of the indicies here are determined dynamically
|
|
|
|
|
*/
|
|
|
|
|
RNA_def_int(ot->srna, "type", 0, INT_MIN, INT_MAX, "Keying Set Number", "Index (determined internally) of the Keying Set to use", 0, 1);
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-13 02:40:56 +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
|
|
|
/* REGISTERED KEYING SETS */
|
2009-04-13 02:40:56 +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
|
|
|
/* Keying Set Type Info declarations */
|
|
|
|
|
ListBase keyingset_type_infos = {NULL, NULL};
|
2009-04-13 02:40:56 +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
|
|
|
/* Built-In Keying Sets (referencing type infos)*/
|
|
|
|
|
ListBase builtin_keyingsets = {NULL, NULL};
|
2009-04-13 02:40:56 +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
|
|
|
/* --------------- */
|
2009-04-13 02:40:56 +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
|
|
|
/* Find KeyingSet type info given a name */
|
|
|
|
|
KeyingSetInfo *ANIM_keyingset_info_find_named (const char name[])
|
2009-04-13 02:40:56 +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
|
|
|
KeyingSetInfo *ksi;
|
2009-04-13 02:40:56 +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
|
|
|
/* sanity checks */
|
|
|
|
|
if ((name == NULL) || (name[0] == 0))
|
|
|
|
|
return NULL;
|
2009-04-13 02:40:56 +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
|
|
|
/* search by comparing names */
|
|
|
|
|
for (ksi = keyingset_type_infos.first; ksi; ksi = ksi->next) {
|
2010-03-24 12:48:03 +00:00
|
|
|
if (strcmp(ksi->idname, name) == 0)
|
== 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 ksi;
|
2009-04-13 02:40:56 +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
|
|
|
/* no matches found */
|
|
|
|
|
return NULL;
|
2009-04-13 02:40:56 +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
|
|
|
/* Find builtin KeyingSet by name */
|
|
|
|
|
KeyingSet *ANIM_builtin_keyingset_get_named (KeyingSet *prevKS, const char name[])
|
2009-04-13 02:40:56 +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
|
|
|
KeyingSet *ks, *first=NULL;
|
2009-04-13 02:40:56 +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
|
|
|
/* sanity checks any name to check? */
|
|
|
|
|
if (name[0] == 0)
|
|
|
|
|
return NULL;
|
2009-04-13 02:40:56 +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
|
|
|
/* get first KeyingSet to use */
|
|
|
|
|
if (prevKS && prevKS->next)
|
|
|
|
|
first= prevKS->next;
|
|
|
|
|
else
|
|
|
|
|
first= builtin_keyingsets.first;
|
2009-04-13 02:40:56 +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
|
|
|
/* loop over KeyingSets checking names */
|
|
|
|
|
for (ks= first; ks; ks= ks->next) {
|
|
|
|
|
if (strcmp(name, ks->name) == 0)
|
|
|
|
|
return ks;
|
|
|
|
|
}
|
2009-04-13 02:40:56 +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
|
|
|
/* no matches found */
|
|
|
|
|
return NULL;
|
2009-04-13 02:40:56 +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
|
|
|
/* --------------- */
|
2009-04-13 02:40:56 +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 the given KeyingSetInfo to the list of type infos, and create an appropriate builtin set too */
|
|
|
|
|
void ANIM_keyingset_info_register (const bContext *C, KeyingSetInfo *ksi)
|
2009-04-13 02:40:56 +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
|
|
|
KeyingSet *ks;
|
2009-04-13 02:40:56 +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
|
|
|
/* create a new KeyingSet
|
|
|
|
|
* - inherit name and keyframing settings from the typeinfo
|
|
|
|
|
*/
|
Keying Sets: BuiltIn vs Absolute Tweaks
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
2010-03-23 11:59:34 +00:00
|
|
|
ks = BKE_keyingset_add(&builtin_keyingsets, ksi->name, 1, ksi->keyingflag);
|
2009-04-13 02:40:56 +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
|
|
|
/* link this KeyingSet with its typeinfo */
|
2010-03-24 12:48:03 +00:00
|
|
|
memcpy(&ks->typeinfo, ksi->idname, sizeof(ks->typeinfo));
|
2009-04-13 02:40:56 +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 type-info to the list */
|
|
|
|
|
BLI_addtail(&keyingset_type_infos, ksi);
|
|
|
|
|
}
|
2009-04-13 02:40:56 +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
|
|
|
/* Remove the given KeyingSetInfo from the list of type infos, and also remove the builtin set if appropriate */
|
|
|
|
|
void ANIM_keyingset_info_unregister (const bContext *C, KeyingSetInfo *ksi)
|
2009-04-13 02:40:56 +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
|
|
|
Scene *scene = CTX_data_scene(C);
|
|
|
|
|
KeyingSet *ks, *ksn;
|
2009-04-13 02:40:56 +00:00
|
|
|
|
Keying Sets: BuiltIn vs Absolute Tweaks
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
2010-03-23 11:59:34 +00:00
|
|
|
/* find relevant builtin KeyingSets which use this, and remove them */
|
|
|
|
|
// TODO: this isn't done now, since unregister is really only used atm when we
|
|
|
|
|
// reload the scripts, which kindof defeats the purpose of "builtin"?
|
|
|
|
|
for (ks= builtin_keyingsets.first; ks; ks= ksn) {
|
== 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
|
|
|
ksn = ks->next;
|
|
|
|
|
|
|
|
|
|
/* remove if matching typeinfo name */
|
2010-03-24 12:48:03 +00:00
|
|
|
if (strcmp(ks->typeinfo, ksi->idname) == 0) {
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
BKE_keyingset_free(ks);
|
|
|
|
|
BLI_freelinkN(&scene->keyingsets, ks);
|
|
|
|
|
}
|
2009-04-13 02:40:56 +00:00
|
|
|
}
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* free the type info */
|
|
|
|
|
BLI_freelinkN(&keyingset_type_infos, ksi);
|
2009-04-13 02:40:56 +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
|
|
|
/* --------------- */
|
2009-04-15 01:10:36 +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
|
|
|
void ANIM_keyingset_infos_exit ()
|
2009-04-15 01:10:36 +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
|
|
|
KeyingSetInfo *ksi, *next;
|
2009-04-15 01:10:36 +00:00
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* free type infos */
|
|
|
|
|
for (ksi=keyingset_type_infos.first; ksi; ksi=next) {
|
|
|
|
|
next= ksi->next;
|
2009-04-15 01:10:36 +00:00
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* free extra RNA data, and remove from list */
|
|
|
|
|
if (ksi->ext.free)
|
|
|
|
|
ksi->ext.free(ksi->ext.data);
|
|
|
|
|
BLI_freelinkN(&keyingset_type_infos, ksi);
|
2009-04-15 01:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
/* free builtin sets */
|
|
|
|
|
BKE_keyingsets_free(&builtin_keyingsets);
|
2009-04-15 01:10:36 +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
|
|
|
/* ******************************************* */
|
|
|
|
|
/* KEYING SETS API (for UI) */
|
2009-10-08 06:39:45 +00:00
|
|
|
|
2010-03-25 11:34:18 +00:00
|
|
|
/* Getters for Active/Indices ----------------------------- */
|
|
|
|
|
|
2009-10-08 06:39:45 +00:00
|
|
|
/* Get the active Keying Set for the Scene provided */
|
|
|
|
|
KeyingSet *ANIM_scene_get_active_keyingset (Scene *scene)
|
|
|
|
|
{
|
Keying Sets: BuiltIn vs Absolute Tweaks
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
2010-03-23 11:59:34 +00:00
|
|
|
/* if no scene, we've got no hope of finding the Keying Set */
|
|
|
|
|
if (scene == NULL)
|
2009-10-08 06:39:45 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
/* currently, there are several possibilities here:
|
|
|
|
|
* - 0: no active keying set
|
|
|
|
|
* - > 0: one of the user-defined Keying Sets, but indices start from 0 (hence the -1)
|
Keying Sets: BuiltIn vs Absolute Tweaks
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
2010-03-23 11:59:34 +00:00
|
|
|
* - < 0: a builtin keying set
|
2009-10-08 06:39:45 +00:00
|
|
|
*/
|
|
|
|
|
if (scene->active_keyingset > 0)
|
|
|
|
|
return BLI_findlink(&scene->keyingsets, scene->active_keyingset-1);
|
Keying Sets: BuiltIn vs Absolute Tweaks
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
2010-03-23 11:59:34 +00:00
|
|
|
else
|
|
|
|
|
return BLI_findlink(&builtin_keyingsets, (-scene->active_keyingset)-1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Get the index of the Keying Set provided, for the given Scene */
|
|
|
|
|
int ANIM_scene_get_keyingset_index (Scene *scene, KeyingSet *ks)
|
|
|
|
|
{
|
|
|
|
|
int index;
|
|
|
|
|
|
|
|
|
|
/* if no KeyingSet provided, have none */
|
|
|
|
|
if (ks == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* check if the KeyingSet exists in scene list */
|
|
|
|
|
if (scene) {
|
|
|
|
|
/* get index and if valid, return
|
|
|
|
|
* - (absolute) Scene KeyingSets are from (>= 1)
|
|
|
|
|
*/
|
|
|
|
|
index = BLI_findindex(&scene->keyingsets, ks);
|
|
|
|
|
if (index != -1)
|
|
|
|
|
return (index + 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* still here, so try builtins list too
|
|
|
|
|
* - builtins are from (<= -1)
|
|
|
|
|
* - none/invalid is (= 0)
|
|
|
|
|
*/
|
|
|
|
|
index = BLI_findindex(&builtin_keyingsets, ks);
|
|
|
|
|
if (index != -1)
|
|
|
|
|
return -(index + 1);
|
|
|
|
|
else
|
|
|
|
|
return 0;
|
2009-10-08 06:39:45 +00:00
|
|
|
}
|
|
|
|
|
|
2010-03-25 11:34:18 +00:00
|
|
|
/* Menu of All Keying Sets ----------------------------- */
|
|
|
|
|
|
|
|
|
|
/* Create (and show) a menu containing all the Keying Sets which can be used in the current context */
|
|
|
|
|
void ANIM_keying_sets_menu_setup (bContext *C, char title[], char op_name[])
|
|
|
|
|
{
|
|
|
|
|
Scene *scene= CTX_data_scene(C);
|
|
|
|
|
KeyingSet *ks;
|
|
|
|
|
uiPopupMenu *pup;
|
|
|
|
|
uiLayout *layout;
|
|
|
|
|
int i = 0;
|
|
|
|
|
|
|
|
|
|
pup= uiPupMenuBegin(C, title, 0);
|
|
|
|
|
layout= uiPupMenuLayout(pup);
|
|
|
|
|
|
|
|
|
|
/* active Keying Set
|
|
|
|
|
* - only include entry if it exists
|
|
|
|
|
*/
|
|
|
|
|
if (scene->active_keyingset) {
|
|
|
|
|
uiItemIntO(layout, "Active Keying Set", 0, op_name, "type", i++);
|
|
|
|
|
uiItemS(layout);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
i++;
|
|
|
|
|
|
|
|
|
|
/* user-defined Keying Sets
|
|
|
|
|
* - these are listed in the order in which they were defined for the active scene
|
|
|
|
|
*/
|
|
|
|
|
if (scene->keyingsets.first) {
|
|
|
|
|
for (ks= scene->keyingsets.first; ks; ks= ks->next) {
|
|
|
|
|
if (ANIM_keyingset_context_ok_poll(C, ks))
|
|
|
|
|
uiItemIntO(layout, ks->name, 0, op_name, "type", i++);
|
|
|
|
|
}
|
|
|
|
|
uiItemS(layout);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* builtin Keying Sets */
|
|
|
|
|
i= -1;
|
|
|
|
|
for (ks= builtin_keyingsets.first; ks; ks= ks->next) {
|
|
|
|
|
/* only show KeyingSet if context is suitable */
|
|
|
|
|
if (ANIM_keyingset_context_ok_poll(C, ks))
|
|
|
|
|
uiItemIntO(layout, ks->name, 0, op_name, "type", i--);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uiPupMenuEnd(C, pup);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ******************************************* */
|
|
|
|
|
/* KEYFRAME MODIFICATION */
|
|
|
|
|
|
|
|
|
|
/* Polling API ----------------------------------------------- */
|
|
|
|
|
|
== 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
|
|
|
/* Check if KeyingSet can be used in the current context */
|
|
|
|
|
short ANIM_keyingset_context_ok_poll (bContext *C, KeyingSet *ks)
|
2009-04-13 02:40:56 +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
|
|
|
if ((ks->flag & KEYINGSET_ABSOLUTE) == 0) {
|
|
|
|
|
KeyingSetInfo *ksi = ANIM_keyingset_info_find_named(ks->typeinfo);
|
|
|
|
|
|
|
|
|
|
/* get the associated 'type info' for this KeyingSet */
|
|
|
|
|
if (ksi == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
// TODO: check for missing callbacks!
|
|
|
|
|
|
|
|
|
|
/* check if it can be used in the current context */
|
|
|
|
|
return (ksi->poll(ksi, C));
|
2009-04-13 02:40:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
== 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
|
|
|
/* Special 'Overrides' Iterator for Relative KeyingSets ------ */
|
|
|
|
|
|
|
|
|
|
/* 'Data Sources' for relative Keying Set 'overrides'
|
|
|
|
|
* - this is basically a wrapper for PointerRNA's in a linked list
|
|
|
|
|
* - do not allow this to be accessed from outside for now
|
|
|
|
|
*/
|
|
|
|
|
typedef struct tRKS_DSource {
|
|
|
|
|
struct tRKS_DSource *next, *prev;
|
|
|
|
|
PointerRNA ptr; /* the whole point of this exercise! */
|
|
|
|
|
} tRKS_DSource;
|
|
|
|
|
|
2009-04-13 02:40:56 +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
|
|
|
/* Iterator used for overriding the behaviour of iterators defined for
|
|
|
|
|
* relative Keying Sets, with the main usage of this being operators
|
|
|
|
|
* requiring Auto Keyframing. Internal Use Only!
|
|
|
|
|
*/
|
|
|
|
|
static void RKS_ITER_overrides_list (KeyingSetInfo *ksi, bContext *C, KeyingSet *ks, ListBase *dsources)
|
2009-04-13 02:40:56 +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
|
|
|
tRKS_DSource *ds;
|
2009-04-13 02:40:56 +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
|
|
|
for (ds = dsources->first; ds; ds = ds->next) {
|
|
|
|
|
/* run generate callback on this data */
|
|
|
|
|
ksi->generate(ksi, C, ks, &ds->ptr);
|
|
|
|
|
}
|
2009-04-13 02:40:56 +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 new data source for relative Keying Sets */
|
|
|
|
|
void ANIM_relative_keyingset_add_source (ListBase *dsources, ID *id, StructRNA *srna, void *data)
|
2009-04-13 02:40:56 +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
|
|
|
tRKS_DSource *ds;
|
2009-04-13 02:40:56 +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
|
|
|
/* sanity checks
|
2010-03-18 07:53:46 +00:00
|
|
|
* - we must have somewhere to output the data
|
|
|
|
|
* - we must have both srna+data (and with id too optionally), or id by itself only
|
== 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
|
|
|
*/
|
2010-03-18 07:53:46 +00:00
|
|
|
if (dsources == 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;
|
2010-03-18 07:53:46 +00:00
|
|
|
if (ELEM(NULL, srna, data) && (id == NULL))
|
|
|
|
|
return;
|
|
|
|
|
|
== 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
|
|
|
/* allocate new elem, and add to the list */
|
|
|
|
|
ds = MEM_callocN(sizeof(tRKS_DSource), "tRKS_DSource");
|
|
|
|
|
BLI_addtail(dsources, ds);
|
2009-04-13 02:40:56 +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
|
|
|
/* depending on what data we have, create using ID or full pointer call */
|
|
|
|
|
if (srna && data)
|
|
|
|
|
RNA_pointer_create(id, srna, data, &ds->ptr);
|
|
|
|
|
else
|
|
|
|
|
RNA_id_pointer_create(id, &ds->ptr);
|
|
|
|
|
}
|
2009-04-13 02:40:56 +00:00
|
|
|
|
|
|
|
|
/* KeyingSet Operations (Insert/Delete Keyframes) ------------ */
|
|
|
|
|
|
|
|
|
|
/* Given a KeyingSet and context info (if required), modify keyframes for the channels specified
|
|
|
|
|
* by the KeyingSet. This takes into account many of the different combinations of using KeyingSets.
|
|
|
|
|
* Returns the number of channels that keyframes were added to
|
|
|
|
|
*/
|
== 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 ANIM_apply_keyingset (bContext *C, ListBase *dsources, bAction *act, KeyingSet *ks, short mode, float cfra)
|
2009-04-13 02:40:56 +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
|
|
|
Scene *scene= CTX_data_scene(C);
|
2009-04-13 02:40:56 +00:00
|
|
|
KS_Path *ksp;
|
|
|
|
|
int kflag=0, success= 0;
|
|
|
|
|
char *groupname= NULL;
|
|
|
|
|
|
2009-11-23 11:58:30 +00:00
|
|
|
/* sanity checks */
|
|
|
|
|
if (ks == NULL)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2009-04-13 02:40:56 +00:00
|
|
|
/* get flags to use */
|
|
|
|
|
if (mode == MODIFYKEY_MODE_INSERT) {
|
|
|
|
|
/* use KeyingSet's flags as base */
|
|
|
|
|
kflag= ks->keyingflag;
|
|
|
|
|
|
|
|
|
|
/* suppliment with info from the context */
|
2009-12-14 12:09:20 +00:00
|
|
|
kflag |= ANIM_get_keyframing_flags(scene, 1);
|
2009-04-13 02:40:56 +00:00
|
|
|
}
|
|
|
|
|
else if (mode == MODIFYKEY_MODE_DELETE)
|
|
|
|
|
kflag= 0;
|
|
|
|
|
|
== 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 relative Keying Sets, poll and build up the paths */
|
|
|
|
|
if ((ks->flag & KEYINGSET_ABSOLUTE) == 0) {
|
|
|
|
|
KeyingSetInfo *ksi = ANIM_keyingset_info_find_named(ks->typeinfo);
|
|
|
|
|
|
|
|
|
|
/* clear all existing paths
|
|
|
|
|
* NOTE: BKE_keyingset_free() frees all of the paths for the KeyingSet, but not the set itself
|
2009-04-13 02:40:56 +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
|
|
|
BKE_keyingset_free(ks);
|
|
|
|
|
|
|
|
|
|
/* get the associated 'type info' for this KeyingSet */
|
|
|
|
|
if (ksi == NULL)
|
|
|
|
|
return MODIFYKEY_MISSING_TYPEINFO;
|
|
|
|
|
// TODO: check for missing callbacks!
|
|
|
|
|
|
|
|
|
|
/* check if it can be used in the current context */
|
|
|
|
|
if (ksi->poll(ksi, C)) {
|
|
|
|
|
/* if a list of data sources are provided, run a special iterator over them,
|
|
|
|
|
* otherwise, just continue per normal
|
2009-12-14 12:09:20 +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
|
|
|
if (dsources)
|
|
|
|
|
RKS_ITER_overrides_list(ksi, C, ks, dsources);
|
|
|
|
|
else
|
|
|
|
|
ksi->iter(ksi, C, ks);
|
2009-10-08 11:29:27 +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
|
|
|
/* if we don't have any paths now, then this still qualifies as invalid context */
|
|
|
|
|
if (ks->paths.first == NULL)
|
|
|
|
|
return MODIFYKEY_INVALID_CONTEXT;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* poll callback tells us that KeyingSet is useless in current context */
|
|
|
|
|
return MODIFYKEY_INVALID_CONTEXT;
|
2009-04-13 02:40:56 +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
|
|
|
|
|
|
|
|
/* apply the paths as specified in the KeyingSet now */
|
|
|
|
|
for (ksp= ks->paths.first; ksp; ksp= ksp->next) {
|
|
|
|
|
int arraylen, i;
|
|
|
|
|
short kflag2;
|
2009-04-13 02:40:56 +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
|
|
|
/* since keying settings can be defined on the paths too, extend the path before using it */
|
|
|
|
|
kflag2 = (kflag | ksp->keyingflag);
|
|
|
|
|
|
|
|
|
|
/* get pointer to name of group to add channels to */
|
|
|
|
|
if (ksp->groupmode == KSP_GROUP_NONE)
|
|
|
|
|
groupname= NULL;
|
|
|
|
|
else if (ksp->groupmode == KSP_GROUP_KSNAME)
|
|
|
|
|
groupname= ks->name;
|
|
|
|
|
else
|
|
|
|
|
groupname= ksp->group;
|
|
|
|
|
|
|
|
|
|
/* init arraylen and i - arraylen should be greater than i so that
|
|
|
|
|
* normal non-array entries get keyframed correctly
|
|
|
|
|
*/
|
|
|
|
|
i= ksp->array_index;
|
|
|
|
|
arraylen= i;
|
|
|
|
|
|
|
|
|
|
/* get length of array if whole array option is enabled */
|
|
|
|
|
if (ksp->flag & KSP_FLAG_WHOLE_ARRAY) {
|
|
|
|
|
PointerRNA id_ptr, ptr;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
|
|
|
|
|
RNA_id_pointer_create(ksp->id, &id_ptr);
|
|
|
|
|
if (RNA_path_resolve(&id_ptr, ksp->rna_path, &ptr, &prop) && prop)
|
|
|
|
|
arraylen= RNA_property_array_length(&ptr, prop);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* we should do at least one step */
|
|
|
|
|
if (arraylen == i)
|
|
|
|
|
arraylen++;
|
|
|
|
|
|
|
|
|
|
/* for each possible index, perform operation
|
|
|
|
|
* - assume that arraylen is greater than index
|
|
|
|
|
*/
|
|
|
|
|
for (; i < arraylen; i++) {
|
|
|
|
|
/* action to take depends on mode */
|
|
|
|
|
if (mode == MODIFYKEY_MODE_INSERT)
|
|
|
|
|
success += insert_keyframe(ksp->id, act, groupname, ksp->rna_path, i, cfra, kflag2);
|
|
|
|
|
else if (mode == MODIFYKEY_MODE_DELETE)
|
|
|
|
|
success += delete_keyframe(ksp->id, act, groupname, ksp->rna_path, i, cfra, kflag2);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* set recalc-flags */
|
|
|
|
|
if (ksp->id) {
|
|
|
|
|
switch (GS(ksp->id->name)) {
|
|
|
|
|
case ID_OB: /* Object (or Object-Related) Keyframes */
|
2009-04-13 02:40:56 +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
|
|
|
Object *ob= (Object *)ksp->id;
|
2009-12-14 12:09:20 +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
|
|
|
ob->recalc |= OB_RECALC;
|
2009-12-14 12:09:20 +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
|
|
|
break;
|
2009-04-13 02:40:56 +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
|
|
|
/* send notifiers for updates (this doesn't require context to work!) */
|
|
|
|
|
WM_main_add_notifier(NC_ANIMATION|ND_KEYFRAME_EDIT, NULL);
|
2009-04-13 02:40:56 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* return the number of channels successfully affected */
|
|
|
|
|
return success;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ************************************************** */
|