| 
									
										
										
										
											2011-02-23 10:52:22 +00:00
										 |  |  | /*
 | 
					
						
							| 
									
										
										
										
											2009-07-02 05:25:14 +00:00
										 |  |  |  * ***** BEGIN GPL LICENSE BLOCK ***** | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * This program is free software; you can redistribute it and/or | 
					
						
							|  |  |  |  * modify it under the terms of the GNU General Public License | 
					
						
							|  |  |  |  * as published by the Free Software Foundation; either version 2 | 
					
						
							|  |  |  |  * of the License, or (at your option) any later version. | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * This program is distributed in the hope that it will be useful, | 
					
						
							|  |  |  |  * but WITHOUT ANY WARRANTY; without even the implied warranty of | 
					
						
							|  |  |  |  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the | 
					
						
							|  |  |  |  * GNU General Public License for more details. | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * You should have received a copy of the GNU General Public License | 
					
						
							|  |  |  |  * along with this program; if not, write to the Free Software Foundation, | 
					
						
							| 
									
										
										
										
											2010-02-12 13:34:04 +00:00
										 |  |  |  * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. | 
					
						
							| 
									
										
										
										
											2009-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
										 |  |  |  */ | 
					
						
							| 
									
										
										
										
											2011-02-27 20:29:51 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | /** \file blender/editors/animation/keyingsets.c
 | 
					
						
							|  |  |  |  *  \ingroup edanimation | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											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"
 | 
					
						
							| 
									
										
										
										
											2011-01-07 18:36:47 +00:00
										 |  |  | #include "BLI_utildefines.h"
 | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | #include "DNA_anim_types.h"
 | 
					
						
							|  |  |  | #include "DNA_scene_types.h"
 | 
					
						
							| 
									
										
										
										
											2010-08-04 04:01:27 +00:00
										 |  |  | #include "DNA_object_types.h"
 | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2010-07-23 01:43:30 +00:00
										 |  |  | #include "BKE_main.h"
 | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | #include "BKE_animsys.h"
 | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | #include "BKE_context.h"
 | 
					
						
							| 
									
										
										
										
											2009-11-24 12:35:06 +00:00
										 |  |  | #include "BKE_depsgraph.h"
 | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | #include "BKE_report.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"
 | 
					
						
							| 
									
										
										
										
											2011-02-27 18:03:19 +00:00
										 |  |  | #include "UI_resources.h"
 | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | #include "WM_api.h"
 | 
					
						
							|  |  |  | #include "WM_types.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #include "RNA_access.h"
 | 
					
						
							|  |  |  | #include "RNA_define.h"
 | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | #include "RNA_enum_types.h"
 | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | #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 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int keyingset_poll_default_add(bContext *C) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							|  |  |  | 	/* as long as there's an active Scene, it's fine */ | 
					
						
							|  |  |  | 	return (CTX_data_scene(C) != NULL); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* poll callback for editing active KeyingSet */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int keyingset_poll_active_edit(bContext *C) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	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 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int keyingset_poll_activePath_edit(bContext *C) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	KeyingSet *ks; | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	if (scene == NULL) | 
					
						
							|  |  |  | 		return 0; | 
					
						
							|  |  |  | 	if (scene->active_keyingset <= 0) | 
					
						
							|  |  |  | 		return 0; | 
					
						
							|  |  |  | 	else | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		ks = BLI_findlink(&scene->keyingsets, scene->active_keyingset - 1); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* 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 ------------------------- */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int add_default_keyingset_exec(bContext *C, wmOperator *UNUSED(op)) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							|  |  |  | 	short flag = 0, keyingflag = 0; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* 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 */ | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	BKE_keyingset_add(&scene->keyingsets, NULL, NULL, flag, keyingflag); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2014-11-16 13:57:58 +01:00
										 |  |  | 	scene->active_keyingset = BLI_listbase_count(&scene->keyingsets); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2009-10-16 10:49:54 +00:00
										 |  |  | 	/* send notifiers */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	WM_event_add_notifier(C, NC_SCENE | ND_KEYINGSET, NULL); | 
					
						
							| 
									
										
										
										
											2009-10-16 10:49:54 +00:00
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	return OPERATOR_FINISHED; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_OT_keying_set_add(wmOperatorType *ot) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							|  |  |  | 	/* identifiers */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->name = "Add Empty Keying Set"; | 
					
						
							|  |  |  | 	ot->idname = "ANIM_OT_keying_set_add"; | 
					
						
							|  |  |  | 	ot->description = "Add a new (empty) Keying Set to the active Scene"; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* callbacks */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->exec = add_default_keyingset_exec; | 
					
						
							|  |  |  | 	ot->poll = keyingset_poll_default_add; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* Remove 'Active' Keying Set ------------------------- */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int remove_active_keyingset_exec(bContext *C, wmOperator *op) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	KeyingSet *ks; | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	/* verify the Keying Set to use:
 | 
					
						
							|  |  |  | 	 *	- use the active one | 
					
						
							|  |  |  | 	 *	- return error if it doesn't exist | 
					
						
							|  |  |  | 	 */ | 
					
						
							|  |  |  | 	if (scene->active_keyingset == 0) { | 
					
						
							| 
									
										
										
										
											2012-10-18 16:25:58 +00:00
										 |  |  | 		BKE_report(op->reports, RPT_ERROR, "No active keying set to remove"); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 		return OPERATOR_CANCELLED; | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
										
										
											2010-05-14 10:28:29 +00:00
										 |  |  | 	else if (scene->active_keyingset < 0) { | 
					
						
							| 
									
										
										
										
											2012-10-18 16:25:58 +00:00
										 |  |  | 		BKE_report(op->reports, RPT_ERROR, "Cannot remove built in keying set"); | 
					
						
							| 
									
										
										
										
											2010-05-14 10:28:29 +00:00
										 |  |  | 		return OPERATOR_CANCELLED; | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	else | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		ks = BLI_findlink(&scene->keyingsets, scene->active_keyingset - 1); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* 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 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	WM_event_add_notifier(C, NC_SCENE | ND_KEYINGSET, NULL); | 
					
						
							| 
									
										
										
										
											2009-10-16 10:49:54 +00:00
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	return OPERATOR_FINISHED; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_OT_keying_set_remove(wmOperatorType *ot) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							|  |  |  | 	/* identifiers */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->name = "Remove Active Keying Set"; | 
					
						
							|  |  |  | 	ot->idname = "ANIM_OT_keying_set_remove"; | 
					
						
							|  |  |  | 	ot->description = "Remove the active Keying Set"; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* callbacks */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->exec = remove_active_keyingset_exec; | 
					
						
							|  |  |  | 	ot->poll = keyingset_poll_active_edit; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* Add Empty Keying Set Path ------------------------- */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int add_empty_ks_path_exec(bContext *C, wmOperator *op) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	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) { | 
					
						
							| 
									
										
										
										
											2012-10-18 16:25:58 +00:00
										 |  |  | 		BKE_report(op->reports, RPT_ERROR, "No active keying set to add empty path to"); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 		return OPERATOR_CANCELLED; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	else | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		ks = BLI_findlink(&scene->keyingsets, scene->active_keyingset - 1); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* don't use the API method for this, since that checks on values... */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	ksp = MEM_callocN(sizeof(KS_Path), "KeyingSetPath Empty"); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	BLI_addtail(&ks->paths, ksp); | 
					
						
							| 
									
										
										
										
											2014-11-16 13:57:58 +01:00
										 |  |  | 	ks->active_path = BLI_listbase_count(&ks->paths); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	ksp->groupmode = KSP_GROUP_KSNAME; // XXX?
 | 
					
						
							|  |  |  | 	ksp->idtype = ID_OB; | 
					
						
							|  |  |  | 	ksp->flag = KSP_FLAG_WHOLE_ARRAY; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	return OPERATOR_FINISHED; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_OT_keying_set_path_add(wmOperatorType *ot) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							|  |  |  | 	/* identifiers */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->name = "Add Empty Keying Set Path"; | 
					
						
							|  |  |  | 	ot->idname = "ANIM_OT_keying_set_path_add"; | 
					
						
							|  |  |  | 	ot->description = "Add empty path to active Keying Set"; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* callbacks */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->exec = add_empty_ks_path_exec; | 
					
						
							|  |  |  | 	ot->poll = keyingset_poll_active_edit; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* Remove Active Keying Set Path ------------------------- */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int remove_active_ks_path_exec(bContext *C, wmOperator *op) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							|  |  |  | 	KeyingSet *ks = BLI_findlink(&scene->keyingsets, scene->active_keyingset - 1); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* if there is a KeyingSet, find the nominated path to remove */ | 
					
						
							|  |  |  | 	if (ks) { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		KS_Path *ksp = BLI_findlink(&ks->paths, ks->active_path - 1); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 		 | 
					
						
							|  |  |  | 		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 { | 
					
						
							| 
									
										
										
										
											2012-10-18 16:25:58 +00:00
										 |  |  | 			BKE_report(op->reports, RPT_ERROR, "No active keying set path to remove"); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 			return OPERATOR_CANCELLED; | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	else { | 
					
						
							| 
									
										
										
										
											2012-10-18 16:25:58 +00:00
										 |  |  | 		BKE_report(op->reports, RPT_ERROR, "No active keying set to remove a path from"); | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 		return OPERATOR_CANCELLED; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	return OPERATOR_FINISHED; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_OT_keying_set_path_remove(wmOperatorType *ot) | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | { | 
					
						
							|  |  |  | 	/* identifiers */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->name = "Remove Active Keying Set Path"; | 
					
						
							|  |  |  | 	ot->idname = "ANIM_OT_keying_set_path_remove"; | 
					
						
							|  |  |  | 	ot->description = "Remove active Path from active Keying Set"; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* callbacks */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->exec = remove_active_ks_path_exec; | 
					
						
							|  |  |  | 	ot->poll = keyingset_poll_activePath_edit; | 
					
						
							| 
									
										
										
										
											2009-10-03 04:21:38 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | /* ************************************************** */ | 
					
						
							|  |  |  | /* KEYING SETS - OPERATORS (for use in UI menus) */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* Add to KeyingSet Button Operator ------------------------ */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int add_keyingset_button_exec(bContext *C, wmOperator *op) | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	KeyingSet *ks = NULL; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	PropertyRNA *prop = NULL; | 
					
						
							|  |  |  | 	PointerRNA ptr = {{NULL}}; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	char *path = NULL; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	short success = 0; | 
					
						
							|  |  |  | 	int index = 0, pflag = 0; | 
					
						
							| 
									
										
										
										
											2014-02-03 18:55:59 +11:00
										 |  |  | 	const bool all = RNA_boolean_get(op->ptr, "all"); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* 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) { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		short flag = 0, keyingflag = 0; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 		 | 
					
						
							|  |  |  | 		/* 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); | 
					
						
							|  |  |  | 		 | 
					
						
							| 
									
										
										
										
											2011-02-04 08:33:07 +00:00
										 |  |  | 		if (IS_AUTOKEY_FLAG(scene, XYZ2RGB))  | 
					
						
							| 
									
										
										
										
											2009-12-14 12:09:20 +00:00
										 |  |  | 			keyingflag |= INSERTKEY_XYZ2RGB; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 			 | 
					
						
							|  |  |  | 		/* call the API func, and set the active keyingset index */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		ks = BKE_keyingset_add(&scene->keyingsets, "ButtonKeyingSet", "Button Keying Set", flag, keyingflag); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 		 | 
					
						
							| 
									
										
										
										
											2014-11-16 13:57:58 +01:00
										 |  |  | 		scene->active_keyingset = BLI_listbase_count(&scene->keyingsets); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	} | 
					
						
							| 
									
										
										
										
											2010-05-14 10:28:29 +00:00
										 |  |  | 	else if (scene->active_keyingset < 0) { | 
					
						
							| 
									
										
										
										
											2012-10-18 16:25:58 +00:00
										 |  |  | 		BKE_report(op->reports, RPT_ERROR, "Cannot add property to built in keying set"); | 
					
						
							| 
									
										
										
										
											2010-05-14 10:28:29 +00:00
										 |  |  | 		return OPERATOR_CANCELLED; | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 	else { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		ks = BLI_findlink(&scene->keyingsets, scene->active_keyingset - 1); | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 	} | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* try to add to keyingset using property retrieved from UI */ | 
					
						
							| 
									
										
										
										
											2014-11-09 21:20:40 +01:00
										 |  |  | 	UI_context_active_but_prop_get(C, &ptr, &prop, &index); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* check if property is able to be added */ | 
					
						
							| 
									
										
										
										
											2010-09-23 20:26:03 +00:00
										 |  |  | 	if (ptr.id.data && ptr.data && prop && RNA_property_animateable(&ptr, prop)) { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		path = RNA_path_from_ID_to_property(&ptr, prop); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 		 | 
					
						
							|  |  |  | 		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 | 
					
						
							|  |  |  | 				 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 				index = 0; | 
					
						
							| 
									
										
										
										
											2009-10-08 06:39:45 +00:00
										 |  |  | 			} | 
					
						
							|  |  |  | 				 | 
					
						
							| 
									
										
										
										
											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); | 
					
						
							| 
									
										
										
										
											2014-11-16 13:57:58 +01:00
										 |  |  | 			ks->active_path = BLI_listbase_count(&ks->paths); | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 			success = 1; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 			 | 
					
						
							|  |  |  | 			/* free the temp path created */ | 
					
						
							|  |  |  | 			MEM_freeN(path); | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	if (success) { | 
					
						
							|  |  |  | 		/* send updates */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		WM_event_add_notifier(C, NC_SCENE | ND_KEYINGSET, NULL); | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 		 | 
					
						
							|  |  |  | 		/* show notification/report header, so that users notice that something changed */ | 
					
						
							|  |  |  | 		BKE_reportf(op->reports, RPT_INFO, "Property added to Keying Set: '%s'", ks->name); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	return (success) ? OPERATOR_FINISHED : OPERATOR_CANCELLED; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_OT_keyingset_button_add(wmOperatorType *ot) | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | { | 
					
						
							|  |  |  | 	/* identifiers */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->name = "Add to Keying Set"; | 
					
						
							|  |  |  | 	ot->idname = "ANIM_OT_keyingset_button_add"; | 
					
						
							| 
									
										
										
										
											2012-05-04 15:00:36 +00:00
										 |  |  | 	ot->description = "Add current UI-active property to current keying set"; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* callbacks */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->exec = add_keyingset_button_exec;  | 
					
						
							| 
									
										
										
										
											2012-10-27 10:42:28 +00:00
										 |  |  | 	//op->poll = ???
 | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* flags */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	/* properties */ | 
					
						
							| 
									
										
										
										
											2011-09-19 12:26:20 +00:00
										 |  |  | 	RNA_def_boolean(ot->srna, "all", 1, "All", "Add all elements of the array to a Keying Set"); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* Remove from KeyingSet Button Operator ------------------------ */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int remove_keyingset_button_exec(bContext *C, wmOperator *op) | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	KeyingSet *ks = NULL; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	PropertyRNA *prop = NULL; | 
					
						
							|  |  |  | 	PointerRNA ptr = {{NULL}}; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	char *path = NULL; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	short success = 0; | 
					
						
							|  |  |  | 	int index = 0; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* 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) { | 
					
						
							| 
									
										
										
										
											2012-10-18 16:25:58 +00:00
										 |  |  | 		BKE_report(op->reports, RPT_ERROR, "No active keying set to remove property from"); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 		return OPERATOR_CANCELLED; | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
										
										
											2010-05-14 10:28:29 +00:00
										 |  |  | 	else if (scene->active_keyingset < 0) { | 
					
						
							| 
									
										
										
										
											2012-10-18 16:25:58 +00:00
										 |  |  | 		BKE_report(op->reports, RPT_ERROR, "Cannot remove property from built in keying set"); | 
					
						
							| 
									
										
										
										
											2010-05-14 10:28:29 +00:00
										 |  |  | 		return OPERATOR_CANCELLED; | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 	else { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		ks = BLI_findlink(&scene->keyingsets, scene->active_keyingset - 1); | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 	} | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* try to add to keyingset using property retrieved from UI */ | 
					
						
							| 
									
										
										
										
											2014-11-09 21:20:40 +01:00
										 |  |  | 	UI_context_active_but_prop_get(C, &ptr, &prop, &index); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2010-09-23 20:26:03 +00:00
										 |  |  | 	if (ptr.id.data && ptr.data && prop) { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		path = RNA_path_from_ID_to_property(&ptr, prop); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 		 | 
					
						
							|  |  |  | 		if (path) { | 
					
						
							|  |  |  | 			KS_Path *ksp; | 
					
						
							|  |  |  | 			 | 
					
						
							|  |  |  | 			/* try to find a path matching this description */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 			ksp = BKE_keyingset_find_path(ks, ptr.id.data, ks->name, path, index, KSP_GROUP_KSNAME); | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 			 | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 			if (ksp) { | 
					
						
							| 
									
										
										
										
											2011-01-04 08:56:25 +00:00
										 |  |  | 				BKE_keyingset_free_path(ks, ksp); | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 				success = 1; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 			} | 
					
						
							|  |  |  | 			 | 
					
						
							|  |  |  | 			/* free temp path used */ | 
					
						
							|  |  |  | 			MEM_freeN(path); | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	if (success) { | 
					
						
							|  |  |  | 		/* send updates */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		WM_event_add_notifier(C, NC_SCENE | ND_KEYINGSET, NULL); | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 		 | 
					
						
							|  |  |  | 		/* show warning */ | 
					
						
							|  |  |  | 		BKE_report(op->reports, RPT_INFO, "Property removed from Keying Set"); | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	return (success) ? OPERATOR_FINISHED : OPERATOR_CANCELLED; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_OT_keyingset_button_remove(wmOperatorType *ot) | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | { | 
					
						
							|  |  |  | 	/* identifiers */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->name = "Remove from Keying Set"; | 
					
						
							|  |  |  | 	ot->idname = "ANIM_OT_keyingset_button_remove"; | 
					
						
							| 
									
										
										
										
											2012-05-04 15:00:36 +00:00
										 |  |  | 	ot->description = "Remove current UI-active property from current keying set"; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* callbacks */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->exec = remove_keyingset_button_exec;  | 
					
						
							| 
									
										
										
										
											2012-10-27 01:46:47 +00:00
										 |  |  | 	//op->poll = ???
 | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* flags */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO; | 
					
						
							| 
									
										
										
										
											2009-09-04 07:26:32 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											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 */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-03-13 09:03:46 +00:00
										 |  |  | static int keyingset_active_menu_invoke(bContext *C, wmOperator *op, const wmEvent *UNUSED(event)) | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	uiPopupMenu *pup; | 
					
						
							|  |  |  | 	uiLayout *layout; | 
					
						
							|  |  |  | 	 | 
					
						
							| 
									
										
										
										
											2012-03-08 04:12:11 +00:00
										 |  |  | 	/* call the menu, which will call this operator again, hence the canceled */ | 
					
						
							| 
									
										
										
										
											2014-11-09 21:20:40 +01:00
										 |  |  | 	pup = UI_popup_menu_begin(C, op->type->name, ICON_NONE); | 
					
						
							|  |  |  | 	layout = UI_popup_menu_layout(pup); | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	uiItemsEnumO(layout, "ANIM_OT_keying_set_active_set", "type"); | 
					
						
							| 
									
										
										
										
											2014-11-09 21:20:40 +01:00
										 |  |  | 	UI_popup_menu_end(C, pup); | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2014-10-28 17:51:06 +01:00
										 |  |  | 	return OPERATOR_INTERFACE; | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | static int keyingset_active_menu_exec(bContext *C, wmOperator *op) | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							|  |  |  | 	int type = RNA_enum_get(op->ptr, "type"); | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	/* If type == 0, it will deselect any active keying set. */ | 
					
						
							|  |  |  | 	scene->active_keyingset = type; | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* send notifiers */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	WM_event_add_notifier(C, NC_SCENE | ND_KEYINGSET, NULL); | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	return OPERATOR_FINISHED; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  |   | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_OT_keying_set_active_set(wmOperatorType *ot) | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	PropertyRNA *prop; | 
					
						
							|  |  |  | 	 | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | 	/* identifiers */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->name = "Set Active Keying Set"; | 
					
						
							|  |  |  | 	ot->idname = "ANIM_OT_keying_set_active_set"; | 
					
						
							| 
									
										
										
										
											2012-05-04 15:00:36 +00:00
										 |  |  | 	ot->description = "Select a new keying set as the active one"; | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* callbacks */ | 
					
						
							| 
									
										
										
										
											2012-03-22 07:26:09 +00:00
										 |  |  | 	ot->invoke = keyingset_active_menu_invoke; | 
					
						
							|  |  |  | 	ot->exec = keyingset_active_menu_exec;  | 
					
						
							|  |  |  | 	ot->poll = ED_operator_areaactive; | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* flags */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	ot->flag = OPTYPE_REGISTER | OPTYPE_UNDO; | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	/* keyingset to use (dynamic enum) */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	prop = RNA_def_enum(ot->srna, "type", DummyRNA_DEFAULT_items, 0, "Keying Set", "The Keying Set to use"); | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	RNA_def_enum_funcs(prop, ANIM_keying_sets_enum_itemf); | 
					
						
							|  |  |  | /*	RNA_def_property_flag(prop, PROP_HIDDEN);*/ | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +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
										 |  |  | /* 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 */ | 
					
						
							| 
									
										
										
										
											2011-02-14 17:55:27 +00:00
										 |  |  | static 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 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | KeyingSetInfo *ANIM_keyingset_info_find_name(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
										 |  |  | 	/* 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 */ | 
					
						
							| 
									
										
										
										
											2010-08-22 14:15:28 +00:00
										 |  |  | 	return BLI_findstring(&keyingset_type_infos, name, offsetof(KeyingSetInfo, idname)); | 
					
						
							| 
									
										
										
										
											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 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | KeyingSet *ANIM_builtin_keyingset_get_named(KeyingSet *prevKS, const char name[]) | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +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) | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		first = prevKS->next; | 
					
						
							| 
									
										
											  
											
												== 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
										 |  |  | 	else | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		first = builtin_keyingsets.first; | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	 | 
					
						
							| 
									
										
											  
											
												== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see 
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
											
										 
											2010-03-16 06:18:49 +00:00
										 |  |  | 	/* loop over KeyingSets checking names */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	for (ks = first; ks; ks = ks->next) { | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 		if (strcmp(name, ks->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
										 |  |  | 			return ks; | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
										
										
											2011-10-23 05:08:02 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	/* complain about missing keying sets on debug builds */ | 
					
						
							|  |  |  | #ifndef NDEBUG
 | 
					
						
							|  |  |  | 	printf("%s: '%s' not found\n", __func__, name); | 
					
						
							|  |  |  | #endif
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												== 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 */ | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_keyingset_info_register(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 | 
					
						
							|  |  |  | 	 */ | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	ks = BKE_keyingset_add(&builtin_keyingsets, ksi->idname, 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
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	/* Copy description... */ | 
					
						
							|  |  |  | 	BLI_strncpy(ks->description, ksi->description, sizeof(ks->description)); | 
					
						
							|  |  |  | 	 | 
					
						
							| 
									
										
											  
											
												== 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 */ | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_keyingset_info_unregister(Main *bmain, 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, *ksn; | 
					
						
							| 
									
										
										
										
											2012-07-06 23:56:59 +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 */ | 
					
						
							| 
									
										
										
										
											2012-07-06 23:56:59 +00:00
										 |  |  | 	/* 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"? */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	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; | 
					
						
							| 
									
										
										
										
											2012-07-06 23:56:59 +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 if matching typeinfo name */ | 
					
						
							| 
									
										
										
										
											2010-03-24 12:48:03 +00:00
										 |  |  | 		if (strcmp(ks->typeinfo, ksi->idname) == 0) { | 
					
						
							| 
									
										
										
										
											2010-07-23 01:43:30 +00:00
										 |  |  | 			Scene *scene; | 
					
						
							| 
									
										
											  
											
												== 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); | 
					
						
							| 
									
										
										
										
											2010-07-23 01:43:30 +00:00
										 |  |  | 			BLI_remlink(&builtin_keyingsets, ks); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 			for (scene = bmain->scene.first; scene; scene = scene->id.next) | 
					
						
							| 
									
										
										
										
											2010-07-23 01:43:30 +00:00
										 |  |  | 				BLI_remlink_safe(&scene->keyingsets, ks); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 			MEM_freeN(ks); | 
					
						
							| 
									
										
											  
											
												== 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
										 |  |  | 	/* 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
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | void ANIM_keyingset_infos_exit(void) | 
					
						
							| 
									
										
										
										
											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 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	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
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2014-04-26 01:44:55 +09:00
										 |  |  | /* Check if the ID appears in the paths specified by the KeyingSet */ | 
					
						
							|  |  |  | bool ANIM_keyingset_find_id(KeyingSet *ks, ID *id) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	/* sanity checks */ | 
					
						
							|  |  |  | 	if (ELEM(NULL, ks, id)) | 
					
						
							|  |  |  | 		return false; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	return BLI_findptr(&ks->paths, id, offsetof(KS_Path, id)) != 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
										 |  |  | /* ******************************************* */ | 
					
						
							|  |  |  | /* 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 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | KeyingSet *ANIM_scene_get_active_keyingset(Scene *scene) | 
					
						
							| 
									
										
										
										
											2009-10-08 06:39:45 +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
										 |  |  | 	/* 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) | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		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 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		return BLI_findlink(&builtin_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
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* Get the index of the Keying Set provided, for the given Scene */ | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | int ANIM_scene_get_keyingset_index(Scene *scene, KeyingSet *ks) | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | { | 
					
						
							|  |  |  | 	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-09-30 11:56:39 +00:00
										 |  |  | /* Get Keying Set to use for Auto-Keyframing some transforms */ | 
					
						
							|  |  |  | KeyingSet *ANIM_get_keyingset_for_autokeying(Scene *scene, const char *tranformKSName) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	/* get KeyingSet to use 
 | 
					
						
							|  |  |  | 	 *	- use the active KeyingSet if defined (and user wants to use it for all autokeying),  | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	 *    or otherwise key transforms only | 
					
						
							| 
									
										
										
										
											2010-09-30 11:56:39 +00:00
										 |  |  | 	 */ | 
					
						
							| 
									
										
										
										
											2011-02-04 08:33:07 +00:00
										 |  |  | 	if (IS_AUTOKEY_FLAG(scene, ONLYKEYINGSET) && (scene->active_keyingset)) | 
					
						
							| 
									
										
										
										
											2010-09-30 11:56:39 +00:00
										 |  |  | 		return ANIM_scene_get_active_keyingset(scene); | 
					
						
							| 
									
										
										
										
											2011-02-04 08:33:07 +00:00
										 |  |  | 	else if (IS_AUTOKEY_FLAG(scene, INSERTAVAIL)) | 
					
						
							| 
									
										
										
										
											2011-10-23 05:08:02 +00:00
										 |  |  | 		return ANIM_builtin_keyingset_get_named(NULL, ANIM_KS_AVAILABLE_ID); | 
					
						
							| 
									
										
										
										
											2010-09-30 11:56:39 +00:00
										 |  |  | 	else  | 
					
						
							|  |  |  | 		return ANIM_builtin_keyingset_get_named(NULL, tranformKSName); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | /* Menu of All Keying Sets ----------------------------- */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | /* Dynamically populate an enum of Keying Sets */ | 
					
						
							| 
									
										
										
										
											2014-01-04 18:08:43 +11:00
										 |  |  | EnumPropertyItem *ANIM_keying_sets_enum_itemf(bContext *C, PointerRNA *UNUSED(ptr), PropertyRNA *UNUSED(prop), bool *r_free) | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | { | 
					
						
							|  |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							|  |  |  | 	KeyingSet *ks; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	EnumPropertyItem *item = NULL, item_tmp = {0}; | 
					
						
							|  |  |  | 	int totitem = 0; | 
					
						
							|  |  |  | 	int i = 0; | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	if (C == NULL) { | 
					
						
							|  |  |  | 		return DummyRNA_DEFAULT_items; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	/* active Keying Set 
 | 
					
						
							|  |  |  | 	 *	- only include entry if it exists | 
					
						
							|  |  |  | 	 */ | 
					
						
							|  |  |  | 	if (scene->active_keyingset) { | 
					
						
							|  |  |  | 		/* active Keying Set */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		item_tmp.identifier = "__ACTIVE__"; | 
					
						
							|  |  |  | 		item_tmp.name = "Active Keying Set"; | 
					
						
							|  |  |  | 		item_tmp.value = i; | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | 		RNA_enum_item_add(&item, &totitem, &item_tmp); | 
					
						
							|  |  |  | 		 | 
					
						
							|  |  |  | 		/* separator */ | 
					
						
							|  |  |  | 		RNA_enum_item_add_separator(&item, &totitem); | 
					
						
							|  |  |  | 	} | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	i++; | 
					
						
							|  |  |  | 	 | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | 	/* user-defined Keying Sets 
 | 
					
						
							|  |  |  | 	 *	- these are listed in the order in which they were defined for the active scene | 
					
						
							|  |  |  | 	 */ | 
					
						
							|  |  |  | 	if (scene->keyingsets.first) { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		for (ks = scene->keyingsets.first; ks; ks = ks->next, i++) { | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | 			if (ANIM_keyingset_context_ok_poll(C, ks)) { | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 				item_tmp.identifier = ks->idname; | 
					
						
							|  |  |  | 				item_tmp.name = ks->name; | 
					
						
							|  |  |  | 				item_tmp.description = ks->description; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 				item_tmp.value = i; | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | 				RNA_enum_item_add(&item, &totitem, &item_tmp); | 
					
						
							|  |  |  | 			} | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 		 | 
					
						
							|  |  |  | 		/* separator */ | 
					
						
							|  |  |  | 		RNA_enum_item_add_separator(&item, &totitem); | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	/* builtin Keying Sets */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	i = -1; | 
					
						
							|  |  |  | 	for (ks = builtin_keyingsets.first; ks; ks = ks->next, i--) { | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | 		/* only show KeyingSet if context is suitable */ | 
					
						
							|  |  |  | 		if (ANIM_keyingset_context_ok_poll(C, ks)) { | 
					
						
							| 
									
										
										
										
											2012-03-08 14:04:06 +00:00
										 |  |  | 			item_tmp.identifier = ks->idname; | 
					
						
							|  |  |  | 			item_tmp.name = ks->name; | 
					
						
							|  |  |  | 			item_tmp.description = ks->description; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 			item_tmp.value = i; | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | 			RNA_enum_item_add(&item, &totitem, &item_tmp); | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	RNA_enum_item_end(&item, &totitem); | 
					
						
							| 
									
										
										
										
											2014-01-04 18:08:43 +11:00
										 |  |  | 	*r_free = true; | 
					
						
							| 
									
										
										
										
											2011-01-03 05:36:52 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	return item; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2010-03-25 11:34:18 +00:00
										 |  |  | /* ******************************************* */ | 
					
						
							|  |  |  | /* 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 */ | 
					
						
							| 
									
										
										
										
											2014-04-01 11:34:00 +11:00
										 |  |  | bool 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) { | 
					
						
							| 
									
										
										
										
											2012-05-05 16:03:57 +00:00
										 |  |  | 		KeyingSetInfo *ksi = ANIM_keyingset_info_find_name(ks->typeinfo); | 
					
						
							| 
									
										
											  
											
												== 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 the associated 'type info' for this KeyingSet */ | 
					
						
							|  |  |  | 		if (ksi == NULL) | 
					
						
							|  |  |  | 			return 0; | 
					
						
							| 
									
										
										
										
											2012-07-06 23:56:59 +00:00
										 |  |  | 		/* TODO: check for missing callbacks! */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												== 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 it can be used in the current context */ | 
					
						
							|  |  |  | 		return (ksi->poll(ksi, C)); | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							| 
									
										
										
										
											2014-04-01 11:34:00 +11:00
										 |  |  | 	return true; | 
					
						
							| 
									
										
										
										
											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
										 |  |  | /* Special 'Overrides' Iterator for Relative KeyingSets ------ */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* 'Data Sources' for relative Keying Set 'overrides' 
 | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  |  *  - this is basically a wrapper for PointerRNA's in a linked list | 
					
						
							| 
									
										
											  
											
												== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see 
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
											
										 
											2010-03-16 06:18:49 +00:00
										 |  |  |  *	- do not allow this to be accessed from outside for now | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | typedef struct tRKS_DSource { | 
					
						
							|  |  |  | 	struct tRKS_DSource *next, *prev; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	PointerRNA ptr;     /* the whole point of this exercise! */ | 
					
						
							| 
									
										
											  
											
												== 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; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-03-01 12:20:18 +00:00
										 |  |  | /* Iterator used for overriding the behavior of iterators defined for 
 | 
					
						
							| 
									
										
											  
											
												== 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
										 |  |  |  * relative Keying Sets, with the main usage of this being operators  | 
					
						
							|  |  |  |  * requiring Auto Keyframing. Internal Use Only! | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 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 */ | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | 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) ------------ */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | /* Given a KeyingSet and context info, validate Keying Set's paths.
 | 
					
						
							|  |  |  |  * This is only really necessary with relative/built-in KeyingSets | 
					
						
							|  |  |  |  * where their list of paths is dynamically generated based on the | 
					
						
							|  |  |  |  * current context info. | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * Returns 0 if succeeded, otherwise an error code: eModifyKey_Returns | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  |  */ | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | short ANIM_validate_keyingset(bContext *C, ListBase *dsources, KeyingSet *ks) | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | 	/* sanity check */ | 
					
						
							| 
									
										
										
										
											2009-11-23 11:58:30 +00:00
										 |  |  | 	if (ks == NULL) | 
					
						
							|  |  |  | 		return 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) { | 
					
						
							| 
									
										
										
										
											2012-05-05 16:03:57 +00:00
										 |  |  | 		KeyingSetInfo *ksi = ANIM_keyingset_info_find_name(ks->typeinfo); | 
					
						
							| 
									
										
											  
											
												== 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
										 |  |  | 		 | 
					
						
							|  |  |  | 		/* 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; | 
					
						
							| 
									
										
										
										
											2012-07-06 23:56:59 +00:00
										 |  |  | 		/* TODO: check for missing callbacks! */ | 
					
						
							| 
									
										
										
										
											2013-03-08 02:15:08 +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
										 |  |  | 		/* 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 */ | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 			// FIXME: we need some error conditions (to be retrieved from the iterator why this failed!)
 | 
					
						
							| 
									
										
										
										
											2014-02-08 06:07:10 +11:00
										 |  |  | 			if (BLI_listbase_is_empty(&ks->paths)) | 
					
						
							| 
									
										
											  
											
												== 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 MODIFYKEY_INVALID_CONTEXT; | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 		else { | 
					
						
							|  |  |  | 			/* poll callback tells us that KeyingSet is useless in current context */ | 
					
						
							| 
									
										
										
										
											2012-11-06 05:25:55 +00:00
										 |  |  | 			// FIXME: the poll callback needs to give us more info why
 | 
					
						
							| 
									
										
											  
											
												== 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 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
										 |  |  | 	 | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | 	/* succeeded; return 0 to tag error free */ | 
					
						
							|  |  |  | 	return 0; | 
					
						
							|  |  |  | }  | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* 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 | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2012-04-29 17:11:40 +00:00
										 |  |  | int ANIM_apply_keyingset(bContext *C, ListBase *dsources, bAction *act, KeyingSet *ks, short mode, float cfra) | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	Scene *scene = CTX_data_scene(C); | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | 	ReportList *reports = CTX_wm_reports(C); | 
					
						
							|  |  |  | 	KS_Path *ksp; | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	int kflag = 0, success = 0; | 
					
						
							| 
									
										
										
										
											2014-04-27 00:22:49 +10:00
										 |  |  | 	const char *groupname = NULL; | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* sanity checks */ | 
					
						
							|  |  |  | 	if (ks == NULL) | 
					
						
							|  |  |  | 		return 0; | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	/* get flags to use */ | 
					
						
							|  |  |  | 	if (mode == MODIFYKEY_MODE_INSERT) { | 
					
						
							|  |  |  | 		/* use KeyingSet's flags as base */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		kflag = ks->keyingflag; | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | 		 | 
					
						
							| 
									
										
										
										
											2014-02-22 02:37:14 +13:00
										 |  |  | 		/* supplement with info from the context */ | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | 		kflag |= ANIM_get_keyframing_flags(scene, 1); | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	else if (mode == MODIFYKEY_MODE_DELETE) | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		kflag = 0; | 
					
						
							| 
									
										
										
										
											2011-08-15 10:37:26 +00:00
										 |  |  | 	 | 
					
						
							|  |  |  | 	/* if relative Keying Sets, poll and build up the paths */ | 
					
						
							|  |  |  | 	success = ANIM_validate_keyingset(C, dsources, ks); | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	if (success != 0) { | 
					
						
							|  |  |  | 		/* return error code if failed */ | 
					
						
							|  |  |  | 		return success; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							| 
									
										
											  
											
												== 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 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 	for (ksp = ks->paths.first; ksp; ksp = ksp->next) { | 
					
						
							| 
									
										
											  
											
												== 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 arraylen, i; | 
					
						
							|  |  |  | 		short kflag2; | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 		 | 
					
						
							| 
									
										
										
										
											2011-02-20 21:32:21 +00:00
										 |  |  | 		/* skip path if no ID pointer is specified */ | 
					
						
							|  |  |  | 		if (ksp->id == NULL) { | 
					
						
							|  |  |  | 			BKE_reportf(reports, RPT_WARNING, | 
					
						
							| 
									
										
										
										
											2012-10-26 17:32:50 +00:00
										 |  |  | 			            "Skipping path in keying set, as it has no ID (KS = '%s', path = '%s[%d]')", | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 			            ks->name, ksp->rna_path, ksp->array_index); | 
					
						
							| 
									
										
										
										
											2011-02-20 21:32:21 +00:00
										 |  |  | 			continue; | 
					
						
							|  |  |  | 		} | 
					
						
							|  |  |  | 		 | 
					
						
							| 
									
										
											  
											
												== 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) | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 			groupname = 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
										 |  |  | 		else if (ksp->groupmode == KSP_GROUP_KSNAME) | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 			groupname = ks->name; | 
					
						
							| 
									
										
											  
											
												== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see 
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
											
										 
											2010-03-16 06:18:49 +00:00
										 |  |  | 		else | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 			groupname = ksp->group; | 
					
						
							| 
									
										
											  
											
												== 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
										 |  |  | 		 | 
					
						
							|  |  |  | 		/* init arraylen and i - arraylen should be greater than i so that
 | 
					
						
							|  |  |  | 		 * normal non-array entries get keyframed correctly | 
					
						
							|  |  |  | 		 */ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 		i = ksp->array_index; | 
					
						
							|  |  |  | 		arraylen = i; | 
					
						
							| 
									
										
											  
											
												== 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 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); | 
					
						
							| 
									
										
											  
											
												Bugfix [#34836] Crash when driver variable has path == 'data'
Most of the places which relied on RNA_path_resolve() did so believing that if
it returned true, that it had found a valid property, and that the returned
pointer+property combination would be what the path referred to. However, it
turns out that if the property at the end of the path turns out to be a
"pointer" property (e.g. "data" for Object.data), this would automatically
become the pointer part, while the prop part would be set to null. Hence, if a
user accidentally (or otherwise) specifies a path for the single-property driver
variable type like this, then Blender would crash.
This commit introduces two convenience functions - RNA_path_resolve_property()
and RNA_path_resolve_property_full() - which mirror/wrap the existing
RNA_path_resolve() functions. The only difference though is that these include a
check to ensure that what was found from resolving the path was in fact a
property (they only return true iff this is the case), and make it explicitly
clear in the name that this is what they will do so that there's no further
confusion. It is possible to do without these wrapper functions by doing these
checks inline, but the few cases that had been patched already were pretty
hideous looking specimens. Using these just make it clearer and simpler for all.
I've also beefed up the docs on these a bit, and changed these to using bools.
											
										 
											2013-04-22 13:22:07 +00:00
										 |  |  | 			if (RNA_path_resolve_property(&id_ptr, ksp->rna_path, &ptr, &prop)) | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 				arraylen = RNA_property_array_length(&ptr, prop); | 
					
						
							| 
									
										
											  
											
												== 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
										 |  |  | 		} | 
					
						
							|  |  |  | 		 | 
					
						
							|  |  |  | 		/* 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) | 
					
						
							| 
									
										
										
										
											2010-11-17 12:02:36 +00:00
										 |  |  | 				success += insert_keyframe(reports, ksp->id, act, groupname, ksp->rna_path, i, cfra, kflag2); | 
					
						
							| 
									
										
											  
											
												== 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
										 |  |  | 			else if (mode == MODIFYKEY_MODE_DELETE) | 
					
						
							| 
									
										
										
										
											2010-11-17 12:02:36 +00:00
										 |  |  | 				success += delete_keyframe(reports, ksp->id, act, groupname, ksp->rna_path, i, cfra, kflag2); | 
					
						
							| 
									
										
											  
											
												== 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
										 |  |  | 		} | 
					
						
							|  |  |  | 		 | 
					
						
							|  |  |  | 		/* set recalc-flags */ | 
					
						
							| 
									
										
										
										
											2011-02-20 21:32:21 +00:00
										 |  |  | 		switch (GS(ksp->id->name)) { | 
					
						
							|  |  |  | 			case ID_OB: /* Object (or Object-Related) Keyframes */ | 
					
						
							|  |  |  | 			{ | 
					
						
							| 
									
										
										
										
											2012-05-08 15:30:00 +00:00
										 |  |  | 				Object *ob = (Object *)ksp->id; | 
					
						
							| 
									
										
										
										
											2011-02-20 21:32:21 +00:00
										 |  |  | 				 | 
					
						
							| 
									
										
										
										
											2013-02-21 19:33:04 +00:00
										 |  |  | 				// XXX: only object transforms?
 | 
					
						
							|  |  |  | 				DAG_id_tag_update(&ob->id, OB_RECALC_OB | OB_RECALC_DATA | OB_RECALC_TIME); | 
					
						
							| 
									
										
										
										
											2013-07-19 15:23:42 +00:00
										 |  |  | 				break; | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 			} | 
					
						
							|  |  |  | 		} | 
					
						
							| 
									
										
										
										
											2011-02-20 21:32:21 +00:00
										 |  |  | 		 | 
					
						
							|  |  |  | 		/* send notifiers for updates (this doesn't require context to work!) */ | 
					
						
							| 
									
										
										
										
											2014-04-24 14:26:53 +12:00
										 |  |  | 		WM_main_add_notifier(NC_ANIMATION | ND_KEYFRAME | NA_ADDED, NULL); | 
					
						
							| 
									
										
										
										
											2009-04-13 02:40:56 +00:00
										 |  |  | 	} | 
					
						
							|  |  |  | 	 | 
					
						
							|  |  |  | 	/* return the number of channels successfully affected */ | 
					
						
							|  |  |  | 	return success; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* ************************************************** */ |