After reviewing this code, it seems that this case can work after all.
However, several things needed to be tweaked:
1) Removed check which stopped parented objects from getting the
visual keying coordinates determined. This actually wasn't doing
anything, given that this case would never occur as...
2) Tweaked the visualkey_can_use() function to also consider parenting
as a cause for visual-keying to be necessary.
Causing a flurry of refresh file prompts post-commit,
Confusing local diffs and causing merge conflicts,
Stating the obvious; redundant and useless...
We shall not miss thou, blasted expand $keywords$
handle/key
This used to be a weird per-curve setting which would happen to get
applied/work correctly if handles were set to "auto", and was a source
of constant confusion for both old and new animators. The main effect
of this handle-type/option was really to just ensure that auto-handles
stayed horizontal, instead of tilting as the keys were moved.
This commit simply changes this from a per-curve to per
keyframe/handle setting.
Visual Keyframing was broken by r.34685, which used another method
which, at the time, appeared to work perfectly fine. Apparently not.
Also, extend/fixed visual keying to work for axis-angle rotations too.
Needs some testing, but should probably work
Reviewed by Tom Musgrove and myself.
From the patch description:
ValterVB on #blendercoders submitted a long list of missing tooltips in Blender, and I went through the list and added all I knew. After that I crowdsourced the rest by putting a spreadsheet on Google docs and having people fill in the missing ones that I didn't know. So if there's some weird tooltip in there that doesn't make sense, that's why.
Thanks to Wolter, spacetug and others on BlenderArtists for contributing tooltips.
Using search for operators showed ambigious names like "Duplicate" or "Delete".
Default names should give at least a descriptive label. In case operators
are collected in a group name-shortening should be handled separaly.
- Fixed problem where just trying to replace existing keyframes would
result in the intepolation set on that keyframe to get lost. This was
mostly an issue if trying to re-block some animation in the middle of
a shot, with the rest of the keys set to Bezier, but the first
keyframe in this new segment needing to be Constant so that we don't
get sloppy automatic interpolation in the way
- Hooked up Media-Play/Stop/Next/Prev controls to animation playback
and keyframe jumping functionality in default keymap in addition the
existing controls. I'm also considering whether to migrate Next/Prev
Keyframe key mappings off the Ctrl-PageUp/Down keys for a more
ergonomic option (i.e. shift <, shift >)
- 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>
