2011-02-04 09:27:25 +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,
|
|
|
|
# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
#
|
|
|
|
# ##### END GPL LICENSE BLOCK #####
|
|
|
|
|
|
|
|
# <pep8 compliant>
|
|
|
|
|
|
|
|
"""
|
|
|
|
Built-In Keying Sets
|
|
|
|
None of these Keying Sets should be removed, as these
|
|
|
|
are needed by various parts of Blender in order for them
|
|
|
|
to work correctly.
|
2011-04-05 11:49:58 +00:00
|
|
|
|
|
|
|
Beware also about changing the order that these are defined
|
|
|
|
here, since this can result in old files referring to the
|
|
|
|
wrong Keying Set as the active one, potentially resulting
|
|
|
|
in lost (i.e. unkeyed) animation.
|
2011-02-04 09:27:25 +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
|
|
|
|
|
|
|
import bpy
|
2011-02-27 15:25:24 +00:00
|
|
|
import keyingsets_utils
|
== 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 KeyingSets
|
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# Location
|
|
|
|
class BUILTIN_KSI_Location(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Location"
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator - use callback for location
|
2011-02-27 15:25:24 +00:00
|
|
|
generate = keyingsets_utils.RKS_GEN_location
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# Rotation
|
|
|
|
class BUILTIN_KSI_Rotation(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Rotation"
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator - use callback for location
|
2011-02-27 15:25:24 +00:00
|
|
|
generate = keyingsets_utils.RKS_GEN_rotation
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# Scale
|
|
|
|
class BUILTIN_KSI_Scaling(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Scaling"
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator - use callback for location
|
2011-02-27 15:25:24 +00:00
|
|
|
generate = keyingsets_utils.RKS_GEN_scaling
|
== 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-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# LocRot
|
|
|
|
class BUILTIN_KSI_LocRot(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "LocRot"
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator
|
2010-09-23 07:50:52 +00:00
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# location
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
|
2010-09-23 07:50:52 +00:00
|
|
|
# rotation
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_rotation(self, context, ks, data)
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# LocScale
|
|
|
|
class BUILTIN_KSI_LocScale(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "LocScale"
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator
|
2010-09-23 07:50:52 +00:00
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# location
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
|
2010-09-23 07:50:52 +00:00
|
|
|
# scale
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_scaling(self, context, ks, data)
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# LocRotScale
|
|
|
|
class BUILTIN_KSI_LocRotScale(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "LocRotScale"
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator
|
2010-09-23 07:50:52 +00:00
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# location
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
|
2010-09-23 07:50:52 +00:00
|
|
|
# rotation
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_rotation(self, context, ks, data)
|
2010-09-23 07:50:52 +00:00
|
|
|
# scale
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_scaling(self, context, ks, data)
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# RotScale
|
|
|
|
class BUILTIN_KSI_RotScale(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "RotScale"
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator
|
2010-09-23 07:50:52 +00:00
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# rotation
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_rotation(self, context, ks, data)
|
2010-09-23 07:50:52 +00:00
|
|
|
# scaling
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_scaling(self, context, ks, data)
|
2011-02-04 09:27:25 +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-02-04 09:27:25 +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
|
|
|
# Location
|
|
|
|
class BUILTIN_KSI_VisualLoc(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Visual Location"
|
|
|
|
|
2010-12-28 11:50:10 +00:00
|
|
|
bl_options = {'INSERTKEY_VISUAL'}
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator - use callback for location
|
2011-02-27 15:25:24 +00:00
|
|
|
generate = keyingsets_utils.RKS_GEN_location
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# Rotation
|
|
|
|
class BUILTIN_KSI_VisualRot(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Visual Rotation"
|
|
|
|
|
2010-09-23 08:15:53 +00:00
|
|
|
bl_options = {'INSERTKEY_VISUAL'}
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator - use callback for rotation
|
2011-02-27 15:25:24 +00:00
|
|
|
generate = keyingsets_utils.RKS_GEN_rotation
|
== 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-02-04 09:27:25 +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
|
|
|
# VisualLocRot
|
|
|
|
class BUILTIN_KSI_VisualLocRot(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Visual LocRot"
|
|
|
|
|
2010-09-23 08:15:53 +00:00
|
|
|
bl_options = {'INSERTKEY_VISUAL'}
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_items
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator
|
2010-09-23 07:50:52 +00:00
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# location
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
|
2010-09-23 07:50:52 +00:00
|
|
|
# rotation
|
2011-02-27 15:25:24 +00:00
|
|
|
keyingsets_utils.RKS_GEN_rotation(self, context, ks, data)
|
== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
|
|
|
|
# ------------
|
|
|
|
|
2011-02-04 09:27:25 +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
|
|
|
# Available
|
|
|
|
class BUILTIN_KSI_Available(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Available"
|
|
|
|
|
2011-04-21 01:21:28 +00:00
|
|
|
# poll - selected objects or selected object with animation data
|
|
|
|
def poll(ksi, context):
|
|
|
|
ob = context.active_object
|
|
|
|
if ob:
|
|
|
|
# TODO: this fails if one animation-less object is active, but many others are selected
|
|
|
|
return ob.animation_data and ob.animation_data.action
|
|
|
|
else:
|
|
|
|
return bool(context.selected_objects)
|
2010-09-23 07:50:52 +00:00
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
2011-02-27 15:25:24 +00:00
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_item
|
2010-09-23 07:50:52 +00:00
|
|
|
|
2011-02-04 09:27:25 +00:00
|
|
|
# generator - use callback for doing this
|
2011-02-27 15:25:24 +00:00
|
|
|
generate = keyingsets_utils.RKS_GEN_available
|
== 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-02-04 09:27:25 +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
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# All properties that are likely to get animated in a character rig
|
|
|
|
class BUILTIN_KSI_WholeCharacter(bpy.types.KeyingSetInfo):
|
|
|
|
bl_label = "Whole Character"
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# these prefixes should be avoided, as they are not really bones
|
|
|
|
# that animators should be touching (or need to touch)
|
|
|
|
badBonePrefixes = (
|
2011-02-04 09:27:25 +00:00
|
|
|
'DEF',
|
|
|
|
'GEO',
|
|
|
|
'MCH',
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
'ORG',
|
|
|
|
'COR',
|
|
|
|
'VIS',
|
|
|
|
# ... more can be added here as you need in your own rigs ...
|
|
|
|
)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# poll - pose-mode on active object only
|
|
|
|
def poll(ksi, context):
|
|
|
|
return ((context.active_object) and (context.active_object.pose) and
|
|
|
|
(context.active_object.mode == 'POSE'))
|
|
|
|
|
|
|
|
# iterator - all bones regardless of selection
|
|
|
|
def iterator(ksi, context, ks):
|
|
|
|
for bone in context.active_object.pose.bones:
|
|
|
|
if not bone.name.startswith(BUILTIN_KSI_WholeCharacter.badBonePrefixes):
|
|
|
|
ksi.generate(context, ks, bone)
|
|
|
|
|
|
|
|
# generator - all unlocked bone transforms + custom properties
|
|
|
|
def generate(ksi, context, ks, bone):
|
|
|
|
# loc, rot, scale - only include unlocked ones
|
|
|
|
ksi.doLoc(ks, bone)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
if bone.rotation_mode in ('QUATERNION', 'AXIS_ANGLE'):
|
|
|
|
ksi.doRot4d(ks, bone)
|
|
|
|
else:
|
|
|
|
ksi.doRot3d(ks, bone)
|
|
|
|
ksi.doScale(ks, bone)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# custom props?
|
|
|
|
ksi.doCustomProps(ks, bone)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# ----------------
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# helper to add some bone's property to the Keying Set
|
2011-02-04 09:27:25 +00:00
|
|
|
def addProp(ksi, ks, bone, prop, index=-1, use_groups=True):
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# add the property name to the base path
|
2011-01-29 09:47:48 +00:00
|
|
|
id_path = bone.path_from_id()
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
id_block = bone.id_data
|
2011-02-04 09:27:25 +00:00
|
|
|
|
|
|
|
if prop.startswith('['):
|
2011-01-29 09:47:48 +00:00
|
|
|
# custom properties
|
|
|
|
path = id_path + prop
|
2011-02-04 09:27:25 +00:00
|
|
|
else:
|
2011-01-29 09:47:48 +00:00
|
|
|
# standard transforms/properties
|
2011-02-27 15:25:24 +00:00
|
|
|
path = keyingsets_utils.path_add_property(id_path, prop)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
2011-01-29 09:47:48 +00:00
|
|
|
# add Keying Set entry for this...
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
if use_groups:
|
|
|
|
ks.paths.add(id_block, path, index, group_method='NAMED', group_name=bone.name)
|
|
|
|
else:
|
|
|
|
ks.paths.add(id_block, path, index)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# ----------------
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# location properties
|
|
|
|
def doLoc(ksi, ks, bone):
|
|
|
|
if bone.lock_location == (False, False, False):
|
|
|
|
ksi.addProp(ks, bone, "location")
|
|
|
|
else:
|
|
|
|
for i in range(3):
|
|
|
|
if not bone.lock_location[i]:
|
|
|
|
ksi.addProp(ks, bone, "location", i)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# rotation properties
|
|
|
|
def doRot4d(ksi, ks, bone):
|
|
|
|
# rotation mode affects the property used
|
|
|
|
if bone.rotation_mode == 'QUATERNION':
|
|
|
|
prop = "rotation_quaternion"
|
|
|
|
elif bone.rotation_mode == 'AXIS_ANGLE':
|
|
|
|
prop = "rotation_axis_angle"
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# add rotation properties if they will
|
|
|
|
if bone.lock_rotations_4d:
|
|
|
|
# can check individually
|
|
|
|
if (bone.lock_rotation == (False, False, False)) and (bone.lock_rotation_w == False):
|
|
|
|
ksi.addProp(ks, bone, prop)
|
|
|
|
else:
|
|
|
|
if bone.lock_rotation_w == False:
|
2011-02-04 09:27:25 +00:00
|
|
|
ksi.addProp(ks, bone, prop, 0) # w = 0
|
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
for i in range(3):
|
|
|
|
if not bone.lock_rotation[i]:
|
2011-02-04 09:27:25 +00:00
|
|
|
ksi.addProp(ks, bone, prop, i + 1) # i + 1, since here x,y,z = 1,2,3, and w=0
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
elif True not in bone.lock_rotation:
|
2011-02-04 09:27:25 +00:00
|
|
|
# if axis-angle rotations get locked as eulers, then it's too messy to allow anything
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# other than all open unless we keyframe the whole lot
|
|
|
|
ksi.addProp(ks, bone, prop)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
def doRot3d(ksi, ks, bone):
|
|
|
|
if bone.lock_rotation == (False, False, False):
|
|
|
|
ksi.addProp(ks, bone, "rotation_euler")
|
|
|
|
else:
|
|
|
|
for i in range(3):
|
|
|
|
if not bone.lock_rotation[i]:
|
|
|
|
ksi.addProp(ks, bone, "rotation_euler", i)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# scale properties
|
|
|
|
def doScale(ksi, ks, bone):
|
2011-02-04 09:27:25 +00:00
|
|
|
if bone.lock_scale == (0, 0, 0):
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
ksi.addProp(ks, bone, "scale")
|
|
|
|
else:
|
|
|
|
for i in range(3):
|
|
|
|
if not bone.lock_scale[i]:
|
|
|
|
ksi.addProp(ks, bone, "scale", i)
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# ----------------
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# custom properties
|
|
|
|
def doCustomProps(ksi, ks, bone):
|
|
|
|
# go over all custom properties for bone
|
2011-02-04 09:27:25 +00:00
|
|
|
for prop, val in bone.items():
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# ignore special "_RNA_UI" used for UI editing
|
|
|
|
if prop == "_RNA_UI":
|
|
|
|
continue
|
2011-02-04 09:27:25 +00:00
|
|
|
|
Character Animation Goodie: "Whole Character" Builtin Keying Set
This commit introduces a new Keying Set: "Whole Character", which is
specially designed for character animators blocking out their
animation. It should make animating with rigs such as the Sintel rigs
(and other "mainstream" setups, though others may also work with a few
modifications) much easier.
It automatically determines which properties on every bone in the
active rig should be keyframed, avoiding an initial set up step where
properties may be missed, or non-animatable properties are also
needlessly keyframed. To do this, it relies on several rules:
1) All bones in the armature, regardless of visibility status are
considered, so that hiding some layers on some keyframes then
keyframing them later won't create problems with earlier poses
changing
2) Bones starting with certain prefixes, i.e. DEF, MCH, VIS, etc. (the
full list is available in the code for this, and can be/is meant to be
modified by riggers in their own versions as they see fit), so that
some bones on hidden layers which shouldn't be seen by animators are
not keyframed
3) Locked transforms AREN'T keyframed
4) All custom properties ARE keyframed - currently this is the best we
can do, as it's hard to tell if they're needed or not, or even if
they're already driven.
2011-01-29 03:01:51 +00:00
|
|
|
# for now, just add all of 'em
|
|
|
|
ksi.addProp(ks, bone, '["%s"]' % (prop))
|
|
|
|
|
2011-04-05 11:49:58 +00:00
|
|
|
###############################
|
|
|
|
|
2011-04-10 10:45:56 +00:00
|
|
|
|
2011-04-05 11:49:58 +00:00
|
|
|
# Delta Location
|
|
|
|
class BUILTIN_KSI_DeltaLocation(bpy.types.KeyingSetInfo):
|
|
|
|
bl_label = "Delta Location"
|
2011-04-10 10:45:56 +00:00
|
|
|
|
2011-04-05 11:49:58 +00:00
|
|
|
# poll - selected objects only (and only if active object in object mode)
|
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_objects
|
|
|
|
|
|
|
|
# iterator - selected objects only
|
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_objects
|
|
|
|
|
|
|
|
# generator - delta location channels only
|
|
|
|
def generate(ksi, context, ks, data):
|
|
|
|
# get id-block and path info
|
|
|
|
id_block, base_path, grouping = keyingsets_utils.get_transform_generators_base_info(data)
|
|
|
|
|
|
|
|
# add the property name to the base path
|
|
|
|
path = keyingsets_utils.path_add_property(base_path, "delta_location")
|
|
|
|
|
|
|
|
# add Keying Set entry for this...
|
|
|
|
if grouping:
|
|
|
|
ks.paths.add(id_block, path, group_method='NAMED', group_name=grouping)
|
|
|
|
else:
|
|
|
|
ks.paths.add(id_block, path)
|
|
|
|
|
|
|
|
|
|
|
|
# Delta Rotation
|
|
|
|
class BUILTIN_KSI_DeltaRotation(bpy.types.KeyingSetInfo):
|
|
|
|
bl_label = "Delta Rotation"
|
2011-04-10 10:45:56 +00:00
|
|
|
|
2011-04-05 11:49:58 +00:00
|
|
|
# poll - selected objects only (and only if active object in object mode)
|
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_objects
|
|
|
|
|
|
|
|
# iterator - selected objects only
|
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_objects
|
|
|
|
|
|
|
|
# generator - delta location channels only
|
|
|
|
def generate(ksi, context, ks, data):
|
|
|
|
# get id-block and path info
|
|
|
|
id_block, base_path, grouping = keyingsets_utils.get_transform_generators_base_info(data)
|
|
|
|
|
|
|
|
# add the property name to the base path
|
|
|
|
# rotation mode affects the property used
|
|
|
|
if data.rotation_mode == 'QUATERNION':
|
|
|
|
path = path_add_property(base_path, "delta_rotation_quaternion")
|
|
|
|
elif data.rotation_mode == 'AXIS_ANGLE':
|
|
|
|
# XXX: for now, this is not available yet
|
|
|
|
#path = path_add_property(base_path, "delta_rotation_axis_angle")
|
2011-04-10 10:45:56 +00:00
|
|
|
return
|
2011-04-05 11:49:58 +00:00
|
|
|
else:
|
|
|
|
path = keyingsets_utils.path_add_property(base_path, "delta_rotation_euler")
|
|
|
|
|
|
|
|
# add Keying Set entry for this...
|
|
|
|
if grouping:
|
|
|
|
ks.paths.add(id_block, path, group_method='NAMED', group_name=grouping)
|
|
|
|
else:
|
|
|
|
ks.paths.add(id_block, path)
|
2011-04-10 10:45:56 +00:00
|
|
|
|
2011-04-05 11:49:58 +00:00
|
|
|
|
|
|
|
# Delta Scale
|
|
|
|
class BUILTIN_KSI_DeltaScale(bpy.types.KeyingSetInfo):
|
|
|
|
bl_label = "Delta Scale"
|
2011-04-10 10:45:56 +00:00
|
|
|
|
2011-04-05 11:49:58 +00:00
|
|
|
# poll - selected objects only (and only if active object in object mode)
|
|
|
|
poll = keyingsets_utils.RKS_POLL_selected_objects
|
|
|
|
|
|
|
|
# iterator - selected objects only
|
|
|
|
iterator = keyingsets_utils.RKS_ITER_selected_objects
|
|
|
|
|
|
|
|
# generator - delta location channels only
|
|
|
|
def generate(ksi, context, ks, data):
|
|
|
|
# get id-block and path info
|
|
|
|
id_block, base_path, grouping = keyingsets_utils.get_transform_generators_base_info(data)
|
|
|
|
|
|
|
|
# add the property name to the base path
|
|
|
|
path = keyingsets_utils.path_add_property(base_path, "delta_scale")
|
|
|
|
|
|
|
|
# add Keying Set entry for this...
|
|
|
|
if grouping:
|
|
|
|
ks.paths.add(id_block, path, group_method='NAMED', group_name=grouping)
|
|
|
|
else:
|
|
|
|
ks.paths.add(id_block, path)
|
|
|
|
|
|
|
|
###############################
|
|
|
|
|
== 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
|
|
|
|
|
|
|
def register():
|
2011-02-11 00:11:17 +00:00
|
|
|
bpy.utils.register_module(__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
|
|
|
|
|
|
|
|
|
|
|
def unregister():
|
2011-02-11 00:11:17 +00:00
|
|
|
bpy.utils.unregister_module(__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
|
|
|
|
|
|
|
if __name__ == "__main__":
|
|
|
|
register()
|