blender/release/scripts/startup/keyingsets_builtins.py

693 lines
23 KiB
Python
Raw Normal View History

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
2011-02-04 09:27:25 +00:00
to work correctly.
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.
Note that these classes cannot be subclassed further; only direct subclasses of KeyingSetInfo
are supported.
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
import keyingsets_utils
from bpy.types import KeyingSetInfo
== Massive Keying Sets Recode == After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen. For a more thorough discussion of this commit, see http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1 ------ The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks. Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage. Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial. Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
###############################
# Built-In KeyingSets
2011-02-04 09:27:25 +00:00
# "Defines"
# Keep these in sync with those in ED_keyframing.h!
ANIM_KS_LOCATION_ID = "Location"
ANIM_KS_ROTATION_ID = "Rotation"
ANIM_KS_SCALING_ID = "Scaling"
ANIM_KS_LOC_ROT_SCALE_ID = "LocRotScale"
ANIM_KS_AVAILABLE_ID = "Available"
ANIM_KS_WHOLE_CHARACTER_ID = "WholeCharacter"
ANIM_KS_WHOLE_CHARACTER_SELECTED_ID = "WholeCharacterSelected"
== 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(KeyingSetInfo):
"""Insert a keyframe on each of the location channels"""
bl_idname = ANIM_KS_LOCATION_ID
2010-09-23 07:50:52 +00:00
bl_label = "Location"
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
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
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(KeyingSetInfo):
"""Insert a keyframe on each of the rotation channels"""
bl_idname = ANIM_KS_ROTATION_ID
2010-09-23 07:50:52 +00:00
bl_label = "Rotation"
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
iterator = keyingsets_utils.RKS_ITER_selected_item
2010-09-23 07:50:52 +00:00
# generator - use callback for rotation
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(KeyingSetInfo):
"""Insert a keyframe on each of the scale channels"""
bl_idname = ANIM_KS_SCALING_ID
2010-09-23 07:50:52 +00:00
bl_label = "Scaling"
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
iterator = keyingsets_utils.RKS_ITER_selected_item
2010-09-23 07:50:52 +00:00
# generator - use callback for scaling
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(KeyingSetInfo):
"""Insert a keyframe on each of the location and rotation channels"""
2010-09-23 07:50:52 +00:00
bl_label = "LocRot"
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
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
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
2010-09-23 07:50:52 +00:00
# rotation
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(KeyingSetInfo):
"""Insert a keyframe on each of the location and scale channels"""
2010-09-23 07:50:52 +00:00
bl_label = "LocScale"
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
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
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
2010-09-23 07:50:52 +00:00
# scale
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(KeyingSetInfo):
"""Insert a keyframe on each of the location, rotation, and scale channels"""
bl_idname = ANIM_KS_LOC_ROT_SCALE_ID
2010-09-23 07:50:52 +00:00
bl_label = "LocRotScale"
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
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
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
2010-09-23 07:50:52 +00:00
# rotation
keyingsets_utils.RKS_GEN_rotation(self, context, ks, data)
2010-09-23 07:50:52 +00:00
# scale
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(KeyingSetInfo):
"""Insert a keyframe on each of the rotation and scale channels"""
2010-09-23 07:50:52 +00:00
bl_label = "RotScale"
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
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
keyingsets_utils.RKS_GEN_rotation(self, context, ks, data)
2010-09-23 07:50:52 +00:00
# scaling
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
# ------------
2016-08-01 01:54:02 +00:00
Bendy Bones: Advanced B-Bones for Easier + Simple Rigging This commit/patch/branch brings a bunch of powerful new options for B-Bones and for working with B-Bones, making it easier for animators to create their own rigs, using fewer bones (which also means hopefully lighter + faster rigs ;) This functionality was first demoed by Daniel at BConf15 Some highlights from this patch include: * You can now directly control the shape of B-Bones using a series of properties instead of being restricted to trying to indirectly control them through the neighbouring bones. See the "Bendy Bones" panel... * B-Bones can be shaped in EditMode to define a "curved rest pose" for the bone. This is useful for things like eyebrows and mouths/eyelids * You can now make B-Bones use custom bones as their reference bone handles, instead of only using the parent/child bones. To do so, enable the "Use Custom Reference Handles" toggle. If none are specified, then the BBone will only use the Bendy Bone properties. * Constraints Head/Tail option can now slide along the B-Bone shape, instead of just linearly interpolating between the endpoints of the bone. For more details, see: * http://aligorith.blogspot.co.nz/2016/05/bendy-bones-dev-update.html * http://aligorith.blogspot.co.nz/2016/05/an-in-depth-look-at-how-b-bones-work.html -- Credits -- Original Idea: Daniel M Lara (pepeland) Original Patch/Research: Jose Molina Additional Development + Polish: Joshua Leung (aligorith) Testing/Feedback: Daniel M Lara (pepeland), Juan Pablo Bouza (jpbouza)
2016-05-17 15:19:06 +00:00
# Bendy Bones
class BUILTIN_KSI_BendyBones(KeyingSetInfo):
"""Insert a keyframe for each of the BBone shape properties"""
bl_label = "BBone Shape"
# poll - use callback for selected bones
poll = keyingsets_utils.RKS_POLL_selected_bones
# iterator - use callback for selected bones
iterator = keyingsets_utils.RKS_ITER_selected_bones
# generator - use generator for bendy bone properties
generate = keyingsets_utils.RKS_GEN_bendy_bones
# ------------
2011-02-04 09:27:25 +00:00
# VisualLocation
class BUILTIN_KSI_VisualLoc(KeyingSetInfo):
"""Insert a keyframe on each of the location channels, taking into account effects of constraints """
"""and relationships"""
2010-09-23 07:50:52 +00:00
bl_label = "Visual Location"
bl_options = {'INSERTKEY_VISUAL'}
2010-09-23 07:50:52 +00:00
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
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
generate = keyingsets_utils.RKS_GEN_location
2010-09-23 07:50:52 +00:00
2011-02-04 09:27:25 +00:00
# VisualRotation
class BUILTIN_KSI_VisualRot(KeyingSetInfo):
"""Insert a keyframe on each of the rotation channels, taking into account effects of constraints """
"""and relationships"""
2010-09-23 07:50:52 +00:00
bl_label = "Visual Rotation"
bl_options = {'INSERTKEY_VISUAL'}
2010-09-23 07:50:52 +00:00
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
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
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
# VisualScaling
class BUILTIN_KSI_VisualScaling(KeyingSetInfo):
"""Insert a keyframe on each of the scale channels, taking into account effects of constraints """
"""and relationships"""
bl_label = "Visual Scaling"
bl_options = {'INSERTKEY_VISUAL'}
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
# iterator - use callback for selected bones/objects
iterator = keyingsets_utils.RKS_ITER_selected_item
# generator - use callback for location
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
# VisualLocRot
class BUILTIN_KSI_VisualLocRot(KeyingSetInfo):
"""Insert a keyframe on each of the location and rotation channels, taking into account effects of constraints """
"""and relationships"""
2010-09-23 07:50:52 +00:00
bl_label = "Visual LocRot"
bl_options = {'INSERTKEY_VISUAL'}
2010-09-23 07:50:52 +00:00
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
2010-09-23 07:50:52 +00:00
# iterator - use callback for selected bones/objects
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
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
2010-09-23 07:50:52 +00:00
# rotation
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
# VisualLocScale
class BUILTIN_KSI_VisualLocScale(KeyingSetInfo):
"""Insert a keyframe on each of the location and scaling channels, taking into account effects of constraints """
"""and relationships"""
bl_label = "Visual LocScale"
bl_options = {'INSERTKEY_VISUAL'}
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
# iterator - use callback for selected bones/objects
iterator = keyingsets_utils.RKS_ITER_selected_item
# generator
def generate(self, context, ks, data):
# location
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
# scaling
keyingsets_utils.RKS_GEN_scaling(self, context, ks, data)
# VisualLocRotScale
class BUILTIN_KSI_VisualLocRotScale(KeyingSetInfo):
"""Insert a keyframe on each of the location, rotation and scaling channels, taking into account effects """
"""of constraints and relationships"""
bl_label = "Visual LocRotScale"
bl_options = {'INSERTKEY_VISUAL'}
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
# iterator - use callback for selected bones/objects
iterator = keyingsets_utils.RKS_ITER_selected_item
# generator
def generate(self, context, ks, data):
# location
keyingsets_utils.RKS_GEN_location(self, context, ks, data)
# rotation
keyingsets_utils.RKS_GEN_rotation(self, context, ks, data)
# scaling
keyingsets_utils.RKS_GEN_scaling(self, context, ks, data)
# VisualRotScale
class BUILTIN_KSI_VisualRotScale(KeyingSetInfo):
"""Insert a keyframe on each of the rotation and scaling channels, taking into account effects of constraints """
"""and relationships"""
bl_label = "Visual RotScale"
bl_options = {'INSERTKEY_VISUAL'}
# poll - use predefined callback for selected bones/objects
poll = keyingsets_utils.RKS_POLL_selected_items
# iterator - use callback for selected bones/objects
iterator = keyingsets_utils.RKS_ITER_selected_item
# generator
def generate(self, context, ks, data):
# rotation
keyingsets_utils.RKS_GEN_rotation(self, context, ks, data)
# scaling
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
# Available
class BUILTIN_KSI_Available(KeyingSetInfo):
"""Insert a keyframe on each of the already existing F-Curves"""
bl_idname = ANIM_KS_AVAILABLE_ID
2010-09-23 07:50:52 +00:00
bl_label = "Available"
# 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
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
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
# All properties that are likely to get animated in a character rig
class BUILTIN_KSI_WholeCharacter(KeyingSetInfo):
"""Insert a keyframe for all properties that are likely to get animated in a character rig """
"""(useful when blocking out a shot)"""
bl_idname = ANIM_KS_WHOLE_CHARACTER_ID
bl_label = "Whole Character"
2011-02-04 09:27:25 +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',
'ORG',
'COR',
'VIS',
# ... more can be added here as you need in your own rigs ...
)
2011-02-04 09:27:25 +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
if not bone.bone.use_connect:
ksi.doLoc(ks, bone)
2011-02-04 09:27:25 +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
Bendy Bones: Advanced B-Bones for Easier + Simple Rigging This commit/patch/branch brings a bunch of powerful new options for B-Bones and for working with B-Bones, making it easier for animators to create their own rigs, using fewer bones (which also means hopefully lighter + faster rigs ;) This functionality was first demoed by Daniel at BConf15 Some highlights from this patch include: * You can now directly control the shape of B-Bones using a series of properties instead of being restricted to trying to indirectly control them through the neighbouring bones. See the "Bendy Bones" panel... * B-Bones can be shaped in EditMode to define a "curved rest pose" for the bone. This is useful for things like eyebrows and mouths/eyelids * You can now make B-Bones use custom bones as their reference bone handles, instead of only using the parent/child bones. To do so, enable the "Use Custom Reference Handles" toggle. If none are specified, then the BBone will only use the Bendy Bone properties. * Constraints Head/Tail option can now slide along the B-Bone shape, instead of just linearly interpolating between the endpoints of the bone. For more details, see: * http://aligorith.blogspot.co.nz/2016/05/bendy-bones-dev-update.html * http://aligorith.blogspot.co.nz/2016/05/an-in-depth-look-at-how-b-bones-work.html -- Credits -- Original Idea: Daniel M Lara (pepeland) Original Patch/Research: Jose Molina Additional Development + Polish: Joshua Leung (aligorith) Testing/Feedback: Daniel M Lara (pepeland), Juan Pablo Bouza (jpbouza)
2016-05-17 15:19:06 +00:00
# bbone properties?
ksi.doBBone(context, ks, bone)
# custom props?
ksi.doCustomProps(ks, bone)
2011-02-04 09:27:25 +00:00
# ----------------
2011-02-04 09:27:25 +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):
# add the property name to the base path
id_path = bone.path_from_id()
id_block = bone.id_data
2011-02-04 09:27:25 +00:00
if prop.startswith('['):
# custom properties
path = id_path + prop
2011-02-04 09:27:25 +00:00
else:
# standard transforms/properties
path = keyingsets_utils.path_add_property(id_path, prop)
2011-02-04 09:27:25 +00:00
# add Keying Set entry for this...
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
# ----------------
2011-02-04 09:27:25 +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
# 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
# add rotation properties if they will
if bone.lock_rotations_4d:
# can check individually
2012-10-08 08:28:05 +00:00
if (bone.lock_rotation == (False, False, False)) and (bone.lock_rotation_w is False):
ksi.addProp(ks, bone, prop)
else:
2012-10-08 08:28:05 +00:00
if bone.lock_rotation_w is False:
2011-02-04 09:27:25 +00:00
ksi.addProp(ks, bone, prop, 0) # w = 0
for i in range(3):
if not bone.lock_rotation[i]:
ksi.addProp(ks, bone, prop, i + 1) # i + 1, since here x/y/z = 1,2,3, and w=0
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
# other than all open unless we keyframe the whole lot
ksi.addProp(ks, bone, prop)
2011-02-04 09:27:25 +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
# scale properties
def doScale(ksi, ks, bone):
2011-02-04 09:27:25 +00:00
if bone.lock_scale == (0, 0, 0):
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
# ----------------
2011-02-04 09:27:25 +00:00
Bendy Bones: Advanced B-Bones for Easier + Simple Rigging This commit/patch/branch brings a bunch of powerful new options for B-Bones and for working with B-Bones, making it easier for animators to create their own rigs, using fewer bones (which also means hopefully lighter + faster rigs ;) This functionality was first demoed by Daniel at BConf15 Some highlights from this patch include: * You can now directly control the shape of B-Bones using a series of properties instead of being restricted to trying to indirectly control them through the neighbouring bones. See the "Bendy Bones" panel... * B-Bones can be shaped in EditMode to define a "curved rest pose" for the bone. This is useful for things like eyebrows and mouths/eyelids * You can now make B-Bones use custom bones as their reference bone handles, instead of only using the parent/child bones. To do so, enable the "Use Custom Reference Handles" toggle. If none are specified, then the BBone will only use the Bendy Bone properties. * Constraints Head/Tail option can now slide along the B-Bone shape, instead of just linearly interpolating between the endpoints of the bone. For more details, see: * http://aligorith.blogspot.co.nz/2016/05/bendy-bones-dev-update.html * http://aligorith.blogspot.co.nz/2016/05/an-in-depth-look-at-how-b-bones-work.html -- Credits -- Original Idea: Daniel M Lara (pepeland) Original Patch/Research: Jose Molina Additional Development + Polish: Joshua Leung (aligorith) Testing/Feedback: Daniel M Lara (pepeland), Juan Pablo Bouza (jpbouza)
2016-05-17 15:19:06 +00:00
# bendy bone properties
def doBBone(ksi, context, ks, pchan):
bone = pchan.bone
2017-07-24 15:27:43 +00:00
Bendy Bones: Advanced B-Bones for Easier + Simple Rigging This commit/patch/branch brings a bunch of powerful new options for B-Bones and for working with B-Bones, making it easier for animators to create their own rigs, using fewer bones (which also means hopefully lighter + faster rigs ;) This functionality was first demoed by Daniel at BConf15 Some highlights from this patch include: * You can now directly control the shape of B-Bones using a series of properties instead of being restricted to trying to indirectly control them through the neighbouring bones. See the "Bendy Bones" panel... * B-Bones can be shaped in EditMode to define a "curved rest pose" for the bone. This is useful for things like eyebrows and mouths/eyelids * You can now make B-Bones use custom bones as their reference bone handles, instead of only using the parent/child bones. To do so, enable the "Use Custom Reference Handles" toggle. If none are specified, then the BBone will only use the Bendy Bone properties. * Constraints Head/Tail option can now slide along the B-Bone shape, instead of just linearly interpolating between the endpoints of the bone. For more details, see: * http://aligorith.blogspot.co.nz/2016/05/bendy-bones-dev-update.html * http://aligorith.blogspot.co.nz/2016/05/an-in-depth-look-at-how-b-bones-work.html -- Credits -- Original Idea: Daniel M Lara (pepeland) Original Patch/Research: Jose Molina Additional Development + Polish: Joshua Leung (aligorith) Testing/Feedback: Daniel M Lara (pepeland), Juan Pablo Bouza (jpbouza)
2016-05-17 15:19:06 +00:00
# This check is crude, but is the best we can do for now
# It simply adds all of these if the bbone has segments
# (and the bone is a control bone). This may lead to some
# false positives...
if bone.bbone_segments > 1:
keyingsets_utils.RKS_GEN_bendy_bones(ksi, context, ks, pchan)
# ----------------
# custom properties
def doCustomProps(ksi, ks, bone):
prop_type_compat = {bpy.types.BoolProperty,
bpy.types.IntProperty,
bpy.types.FloatProperty}
# go over all custom properties for bone
for prop in bone.keys():
# ignore special "_RNA_UI" used for UI editing
if prop == "_RNA_UI":
continue
2011-02-04 09:27:25 +00:00
# for now, just add all of 'em
prop_rna = type(bone).bl_rna.properties.get(prop, None)
if prop_rna is None:
prop_path = '["%s"]' % prop
if bone.path_resolve(prop_path, False).rna_type in prop_type_compat:
ksi.addProp(ks, bone, prop_path)
elif prop_rna.is_animatable:
ksi.addProp(ks, bone, prop)
# All properties that are likely to get animated in a character rig, only selected bones.
2018-07-03 04:27:53 +00:00
class BUILTIN_KSI_WholeCharacterSelected(KeyingSetInfo):
"""Insert a keyframe for all properties that are likely to get animated in a character rig """
"""(only selected bones)"""
bl_idname = ANIM_KS_WHOLE_CHARACTER_SELECTED_ID
bl_label = "Whole Character (Selected bones only)"
# iterator - all bones regardless of selection
def iterator(ksi, context, ks):
# Use either the selected bones, or all of them if none are selected.
bones = context.selected_pose_bones or context.active_object.pose.bones
for bone in bones:
if bone.name.startswith(BUILTIN_KSI_WholeCharacter.badBonePrefixes):
continue
ksi.generate(context, ks, bone)
# Poor man's subclassing. Blender breaks when we actually subclass BUILTIN_KSI_WholeCharacter.
poll = BUILTIN_KSI_WholeCharacter.poll
generate = BUILTIN_KSI_WholeCharacter.generate
addProp = BUILTIN_KSI_WholeCharacter.addProp
doLoc = BUILTIN_KSI_WholeCharacter.doLoc
doRot4d = BUILTIN_KSI_WholeCharacter.doRot4d
doRot3d = BUILTIN_KSI_WholeCharacter.doRot3d
doScale = BUILTIN_KSI_WholeCharacter.doScale
doBBone = BUILTIN_KSI_WholeCharacter.doBBone
doCustomProps = BUILTIN_KSI_WholeCharacter.doCustomProps
###############################
# Delta Location
2018-07-03 04:27:53 +00:00
class BUILTIN_KSI_DeltaLocation(KeyingSetInfo):
"""Insert keyframes for additional location offset"""
bl_label = "Delta Location"
# 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(KeyingSetInfo):
"""Insert keyframes for additional rotation offset"""
bl_label = "Delta Rotation"
# 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 = keyingsets_utils.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")
return
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)
# Delta Scale
class BUILTIN_KSI_DeltaScale(KeyingSetInfo):
"""Insert keyframes for additional scaling factor"""
bl_label = "Delta Scale"
# 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)
###############################
2018-07-03 04:27:53 +00:00
# Note that this controls order of options in 'insert keyframe' menu.
# Better try to keep some logical order here beyond mere alphabetical one, also because of menu entries shortcut.
# See also T51867.
classes = (
BUILTIN_KSI_Available,
BUILTIN_KSI_Location,
BUILTIN_KSI_Rotation,
BUILTIN_KSI_Scaling,
BUILTIN_KSI_LocRot,
BUILTIN_KSI_LocRotScale,
BUILTIN_KSI_LocScale,
BUILTIN_KSI_RotScale,
BUILTIN_KSI_DeltaLocation,
BUILTIN_KSI_DeltaRotation,
BUILTIN_KSI_DeltaScale,
BUILTIN_KSI_VisualLoc,
BUILTIN_KSI_VisualRot,
BUILTIN_KSI_VisualScaling,
BUILTIN_KSI_VisualLocRot,
BUILTIN_KSI_VisualLocRotScale,
BUILTIN_KSI_VisualLocScale,
BUILTIN_KSI_VisualRotScale,
BUILTIN_KSI_BendyBones,
BUILTIN_KSI_WholeCharacter,
BUILTIN_KSI_WholeCharacterSelected,
)
== 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():
from bpy.utils import register_class
for cls in classes:
register_class(cls)
== 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():
from bpy.utils import unregister_class
for cls in classes:
unregister_class(cls)
== 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()