- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
Moving this code to the same method as is used for Apply Visual
Transform (for bones case), which uses standardised decomposition
methods instead of the improvised ones used here before. This was in
an attempt to get IK chains Visual Keyed correctly, though this
doesn't seem to have improved the situation much.
Also, the decompositon for objects here now takes care of euler
rotation modes.
TODO: other rotation modes should get included here too...
Scene (Toolsettings, i.e. alongside "layered" option for using NLA
while doing auto-keying)
This option makes all Auto-Keying operations use the active Keying Set
to carry out keyframing operations instead of picking and choosing
their own Keying Sets to use, thus cutting down on the number of
unwanted keys.
Warning: if the older userpref option was enabled in an old
startup.blend, it may be difficult to turn this option off.
Drivers created from the Properties Editor for Materials and Textures
will now be created on Object-level instead of on their owner
Material/Texture as for their keyframes.
The intention of this hack is to allow users to be able to easily set
up drivers for materials and textures. Without this hack, users would
have had to do this manually via the Datablocks editor (I've described
this method a few times in detail, though this still attracts
complaints), as the way the depsgraph works does not allow ID blocks
other than Objects and directly-linked Object data to be driven. As a
result, although this hack can be done for these two cases, there are
no workarounds possible for Scene and Scene-linked settings.
There are 2 issues that will be noticed with this approach:
1) There may be confusion over why the drivers are found under Object
level and not Material/Texture level.
2) Driver status will not be shown in the buttons, leading to attempts
to try to keyframe the properties directly later and subsequent
confusion when finding that that won't work.
However, these are the sacrifices we'll need to make to get easy-setup
working in the meantime until the proper fixes can be done.
Keyframing operators now use a dynamically-generated enum for their
"type" property, which determines the Keying Set to use for keyframing
instead of the obscure "index" values which were determined
internally. Internally though, these same indices are still being used
:)
Notes:
- I've kept the menu-building function and the special "menu" operator
for now, since it's better to not "pollute" the actual insert
keyframes operator with hardcoded menu-showing logic. Instead, the
menu operator does that, so that if you like, you could write another
such wrapper that works differently.
- The 'type' properties could have the PROP_HIDDEN flags removed,
though I think it's cleaner to leave these without this option for
now.
* Keyframing operators now use the reports system for displaying all its error messages.
- The benefit of this is that users no longer need to check the console for error messages if keyframing fails.
- Unfortunately, reports are not currently viewable in any space/view in Blender, so...
* Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed.
This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain.
* Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
While I was looking in outliner.c, made some changes to let extra passes display
there such as environment (commented out before due to a previous limitation).
Also changed outliner object visbility/selectability/renderability toggles to use
RNA buttons so you can insert keyframes with RMB menu etc.
Now, when the mode is 'replace', no F-Curves are created during keyframing (i.e. only existing F-Curves are used).
---
Also, fixed missing line in previous commit for Select Linked.
* Fixed the way the operator was checking for what the user wanted when using the operator
* Added a few specific defines to a copy of the gesture border modal keymap (added one for zooming only) labelled 'In' and 'Out' which make this more useful than being hacked to use select and deselect
This commit fixes reports #21638 and #21818, which were both also Durian feature requests.
Cbanges:
* Added new default setting for the type of handles created when creating keyframes. This can be found in the user-preferences, and is used whenever existing keyframes aren't being overwritten (instead of the value being always taken from the keyframes either side, #21638).
* When keyframing over existing keyframes, only the values will be changed. The handles will be offset by the same amount that the value of the keyframe changed, though how well this works in practice still needs to be tested more thoroughly (#21818, already fixed earlier, but this commit is the full fix).
* When 'free' handles are added by default, they are offset to be +/- 1 frame on either side of the keyframe so that it is obvious that they can be moved. However, they just take the same value of the keyframe since this is easiest.
* Properly initialising handle colour defaults for 3D-View and Graph Editor. Graph Editor's theme userprefs also show these settings now, though the layout is really quick hack-style.
* Fixed all the dangerous code added in 27907. Using the code there, scripters could corrupt animation files in ways which would render them useless, with channels not appearing in any animation editors, and others not getting evaluated at all.
* Partial fix of bug 21818, by disabling destructive replacement of keyframes. Will followup this commit with a more comprehensive commit which gets rid of the rest of the problems, by incorporating some requests from Durian team.
* Fixed problems with users being able to see+edit the name of the active Keying Set in the Scene buttons. There is still a bug though with the list widget given how the indices are now interpreted...
* Added operator (Ctrl Shift Alt I) to show menu for changing the active Keying Set in the 3D view (todo item from last commit)
* KeyingSetInfo (i.e. the Builtin Keying Set classes) can now be accessed from Keying Set instances with ks.type_info
* Added ks.remove_all_paths() function to remove all the paths for a Keying Set.
---
These two changes mean that builtin Keying Sets could be refreshed in response to context changes by doing:
<code>
ks = bpy.context.scene.active_keying_set
if ks.absolute==False and ks.type_info:
ksi = ks.type_info
# remove existing paths to fill with new
ks.remove_all_paths()
# check if Keying Set can be used in current context
if ksi.poll(bpy.context):
# call iterator() which calls generate() and re-populates paths list
ksi.iterator(bpy.context, ks)
</code>
And then, once this has been done, the paths that the Keying Set will operate on can be accessed as
<code>
paths = bpy.context.scene.active_keying_set.paths
</code>
Only source/blender/editors/ dir, should not give errors on different platforms
Only removing: UI_*.h, ED_*.h, WM_*.h, DNA_*.h, IMB_*.h, RNA_*.h, PIL_*.h
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.
Inserting keyframes for properties that don't already have F-Curves shouldn't occur if auto keyframing is set to 'replace' only (i.e. see timeline -> frame -> autokey mode menu for details).
When the API function is passed -1 for the index, non-array properties now get keyframed properly too. This fixes problems with the keyframe_insert() method on structs in the Py-API not working.
F-Curves now internally store radians again instead of degrees.
- This solves problems with inconsistencies when working with drivers.
- No need to version patch old files, potentially screwing them up. As such, removed the version patching for F-Curves.
- Is better suited to optionally showing radians throughout the UI instead or degrees.
As a result, values are now converted on the fly in the Graph Editor for display and operators that operate on values. I've made the conversion system for this rather general, so that other unit type conversions can also be hooked up with the type conversion backend.
Also, made some tweaks to F-Curve RNA wrapping to make it represent the data better.
TODO:
- Transform code currently still needs to be corrected to work with these changes. Currently moving keyframes for rotation curves will make them change too rapidly vertically when using degrees.
* Select Grouped
Selects bones in the same layer or same group as the selected ones. Optimised the code for the select same groups too.
* Flip Quats
Flips quaternion values so that the rotation progresses over a different path while maintaining the same endpoint orientations.
Rotations are now stored internally as radians, while exposing degrees in the UI -
in the graph editor and UI controls. This is done in two areas:
1) Using the unit system to convert RNA data to display as degrees in the UI controls
2) FCurves now use degrees for rotation, so you can edit in the graph editor what
you see in the UI.
All rotation data is consistently accessible in DNA and RNA as radians, degrees are only
used for the UI controls and graph editor.
This commit includes conversions will convert old files (stored data and also fcurve data)
to the new units, hopefully everything should go smoothly!
Part of this also changes a few properties that were hard-coded as degrees before (such
as IK pole angle and brush texture rotation) to also use the same consistent system of
radians (dna/rna) and degrees (ui).
Thanks to Joshua for hints and review here too.
