== Massive Keying Sets Recode ==
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
2010-03-16 06:18:49 +00:00
|
|
|
# Built-In Keying Sets
|
|
|
|
# None of these Keying Sets should be removed, as these
|
|
|
|
# are needed by various parts of Blender in order for them
|
|
|
|
# to work correctly.
|
|
|
|
|
|
|
|
import bpy
|
|
|
|
from keyingsets_utils import *
|
|
|
|
|
|
|
|
###############################
|
|
|
|
# Built-In KeyingSets
|
|
|
|
|
|
|
|
# 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
generate = RKS_GEN_location
|
|
|
|
|
== 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
generate = 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
|
|
|
# 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
generate = 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
|
|
|
|
== 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# location
|
|
|
|
RKS_GEN_location(self, context, ks, data)
|
|
|
|
# rotation
|
|
|
|
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
|
|
|
|
|
|
|
# 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# location
|
|
|
|
RKS_GEN_location(self, context, ks, data)
|
|
|
|
# scale
|
|
|
|
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
|
|
|
|
|
|
|
# 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# location
|
|
|
|
RKS_GEN_location(self, context, ks, data)
|
|
|
|
# rotation
|
|
|
|
RKS_GEN_rotation(self, context, ks, data)
|
|
|
|
# scale
|
|
|
|
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
|
|
|
|
|
|
|
# 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# rotation
|
|
|
|
RKS_GEN_rotation(self, context, ks, data)
|
|
|
|
# scaling
|
|
|
|
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
|
|
|
# ------------
|
|
|
|
|
|
|
|
# Location
|
|
|
|
class BUILTIN_KSI_VisualLoc(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Visual Location"
|
|
|
|
|
|
|
|
insertkey_visual = True
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected bones/objects
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
generate = RKS_GEN_location
|
|
|
|
|
== 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
generate = 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
|
|
|
|
|
|
|
# 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
|
|
|
|
poll = RKS_POLL_selected_items
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
def generate(self, context, ks, data):
|
|
|
|
# location
|
|
|
|
RKS_GEN_location(self, context, ks, data)
|
|
|
|
# rotation
|
|
|
|
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
|
|
|
|
|
|
|
# ------------
|
|
|
|
|
|
|
|
# Available
|
|
|
|
class BUILTIN_KSI_Available(bpy.types.KeyingSetInfo):
|
2010-09-23 07:50:52 +00:00
|
|
|
bl_label = "Available"
|
|
|
|
|
|
|
|
# poll - use predefined callback for selected objects
|
|
|
|
# TODO: this should really check whether the selected object (or datablock)
|
|
|
|
# has any animation data defined yet
|
|
|
|
poll = RKS_POLL_selected_objects
|
|
|
|
|
|
|
|
# iterator - use callback for selected bones/objects
|
|
|
|
iterator = RKS_ITER_selected_item
|
|
|
|
|
|
|
|
# generator - use callback for location
|
|
|
|
generate = 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
|
|
|
|
|
|
|
###############################
|
|
|
|
|
|
|
|
classes = [
|
2010-09-23 07:50:52 +00:00
|
|
|
BUILTIN_KSI_Location,
|
|
|
|
BUILTIN_KSI_Rotation,
|
|
|
|
BUILTIN_KSI_Scaling,
|
|
|
|
|
|
|
|
BUILTIN_KSI_LocRot,
|
|
|
|
BUILTIN_KSI_LocScale,
|
|
|
|
BUILTIN_KSI_LocRotScale,
|
|
|
|
BUILTIN_KSI_RotScale,
|
|
|
|
|
|
|
|
BUILTIN_KSI_VisualLoc,
|
|
|
|
BUILTIN_KSI_VisualRot,
|
|
|
|
BUILTIN_KSI_VisualLocRot,
|
|
|
|
|
|
|
|
BUILTIN_KSI_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
|
|
|
]
|
|
|
|
|
|
|
|
|
|
|
|
def register():
|
|
|
|
register = bpy.types.register
|
|
|
|
for cls in classes:
|
|
|
|
register(cls)
|
|
|
|
|
|
|
|
|
|
|
|
def unregister():
|
|
|
|
unregister = bpy.types.unregister
|
|
|
|
for cls in classes:
|
|
|
|
unregister(cls)
|
|
|
|
|
|
|
|
if __name__ == "__main__":
|
|
|
|
register()
|
|
|
|
|
|
|
|
###############################
|