This commit basically disables the RNA update caches for now, and
introduces a workaround/hack to ensure that modifier properties still
work when animated/driven. The whole way that updates currently get
handled needs reviewing in future.
Fix provided by Brecht.
linked
Shapekey actions weren't getting copied when their owner data was.
This was due to the IMO totally convoluted way in which the duplicate
action flags have been set up:
- the function to copy animdata takes a param to specify whether
actions are copied or not, but this is never touched (i.e. this always
just gets FALSE passed in)
- instead, we jump around in hoops later figuring out whether the
userpref wants copying to occur, then fixing up the links
IIRC, part of this may be due to a desire/need to not duplicate
actions when dealing with NodeTree copies for multi-threaded
rendering, but at the expense of complicating everything else.
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$
These are basically just for specifying when a speaker should fire off
it's soundclip, and as such, many NLA operations are irrelevant for
it. They can only be specified on object-level for speaker objects.
I've still got some UI tweaks I'll need to work on in order for these
to be able to be added even when the speaker doesn't have any NLA
tracks yet. (EDIT: while typing this, I had an idea for how to do
this, but that'll be for next commit). In the mean time, you'll need
to add a single keyframe for the object, snowflake that action and
delete the NLA strip before you can start editing.
This fixes bug #26764 and several others like it, where modifier
properties (and others, but most visibly modifiers) would not do
anything when animated or driven, as modifier properties require the
RNA update calls to tag the modifiers to get recalculated.
While just adding a call to RNA_property_update() could have gotten
this working (as per the Campbell's patch attached in the report, and
also my own attempt #25881). However, on production rigs, the
performance cost of this is untenatable (on my own tests, without
these updates, I was getting ~5fps on such a rig, but only 0.9fps or
possibly even worse with the updates added).
Hence, this commit adds a property-update caching system to the RNA
level, which aims to reduce to the number of times that the update
functions end up needing to get called.
While this is much faster than without the caching, I also added an
optimisation for pose bones (which are numerous in production rigs) so
that their property updates are skipped, since they are useless to the
animsys (they only tag the depsgraph for updating). This gets things
moving at a more acceptable framerate.
* When clicking on "Animation" items in the Outliner, there's now a
menu containing from which you can change the action used, and
refresh/delete all drivers.
* Moved action-setting logic for AnimData actions to a single utility
function in anim_sys, since this was starting to be done in too many
places already.
* Fixed Outliner refresh bug after changing the active action
blocks via PyAPI/RNA
For example:
ob = bpy.context.active_object # assumes default cube has some drivers
added already before running script
dst = bpy.data.objects["Camera"]
adt = dst.animation_data_create()
for driver in ob.animation_data.drivers:
new_driver = adt.drivers.from_existing(driver)
Actions now get tagged with an ID-code, which is used to determine
what ID-blocks they can be assigned to. This ensures that material
actions cannot be assigned to the object-level for example.
* Action lists in general will now show only the actions that can be
set for that particular slot. This prevents selection of invalid
actions, and helps cut down the list of actions.
** An exception here is the Add Action Clip in NLA Editor, which will
show all actions but will only add where appropriate. This is because
it's not easy/possible to tell in advance which blocktypes to filter
for when building this list. (TODO?)
* The "Action Editor" is now strictly for object-level action
editing+setting now. This avoids repeateded confusion by people who
try using this to view their shapekey actions, which should go to the
Shape Key Editor instead!
** A context switcher for the legitimate times where this capability
might come in handy is still being investigated.
* "Floating" actions (i.e. actions in some action_library.blend) are
NOT able to be automatically tagged until they are assigned to some
datablocks (i.e. loaded onto the rig + played back once). It is
possible to write scripts that check for certain RNA-paths and "guess"
what datablocks they work on, but it is recommended that you load up
the Datablocks Viewer, and go through such actions by hand, setting
the "ID Root Type" property as appropriate per action.
Missing null check for "improper" driver variables.
------
Also, this commit includes some WIP NLA evaluation reshuffling which
should be harmless. I had originally intended this for a later
commit...
- 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.
compositor
This commit fixes the original bug reported here by adding some
methods to move the relevant F-Curves (and drivers) over to the new
Node-Tree's (i.e. group-node) AnimData. Animated nodes which
subsequently get grouped will still be able to animate as a result of
this commit.
TODO's:
- Ungrouping now will not yet merge the animation back (or at least
copy it)
- Buttons for nodes freshly grouped do not correctly show animated
status indicators for some reason, yet normal animation does
Some AnimData looping functions were not updated to take into account
the addition of AnimData for some additional datatypes (i.e. meshes
and lattices) as well as the changes to make nested nodetrees (i.e.
for Material and Texture nodes).
This allows manual (point by point) animation of their control verts,
although many other settings cannot really be animated with any
visible effects yet. Interestingly, lattices also had IPO block
pointers, though they were never really used (AFAIK).
Todo:
- Animation Editor support has yet to be added. I've got a few other
things to add to, so will group those changes together.
Binding code had off-by-1 error, which meant that when "Even Divisions" was disabled the length of the wrong bone would get used.
This error was most noticeable when the lengths of the bones were quite different - for example, a chain with 3 bones of increasing length. Thanks to "Julius" on BlenderArtists for catching this. Cheers!
---
Also, simplified the binding code loop a bit to prevent this sort of error in future.
Playback now works. The problem was that material/texture nodetrees were getting ignored completely, as I was assuming that all of these existed in the main->nodetree collection when in fact only the "group" nodetrees lived there. I don't really agree with this, but that's the way it is...
TODO: animation editor support still to come
- use sizeof() in more places.
- fixed some off by 1 bugs copying strings. setting curve font family for instance was 1 char too short.
- replace strncpy and strcpy with BLI_strncpy
Now the active strip doesn't just get cleared on fileload, but is relinked properly.
I had originally intended that files shouldn't be able to be saved with NLA data still in Tweakmode, but this turns out to be a bit more troublesome to get working as that would make undo keep popping out of this mode too.
Also reverting 32743 (bugfix for 24418), which was a hack around this.
After discussions with Campbell regarding #24336 and #24309, we've decided to make this property for curves to only get set when an F-Curve explicitly animates it.
As a consequence...
- ALL OLD FILES using follow-path constraints that depended on this changed behaviour will currently need manual patching to add an appropriate F-Curve
- Ctrl-P (Parenting to Curves -> Follow Path option) will now automatically create such F-Curves mimicking the old behaviour so that creating camera-following-path setups still works smoothly.
- Directly adding a Follow Path constraint bypasses this, so you'll need to manually add such F-Curves if you need them.
The main problem with the old approach was that there were many cases in which curve data could get added but the ctime would be incorrect until a frame change (i.e. on render) flushed this.
When editing an action used by a NLA strip and editing it 'in place' (controlled by pin icon on green 'tweaking' channel), the animation would only get played back in the action's original frame range while the keyframes were still displayed in the strip-altered positions.
This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
* With multiple objects selected, only one of the objects got keyframed. The code which was checking for duplicate paths was wrongly assuming to ignore the ID-block used still.
* Not registering a Keying Set as 'builtin' would crash on startup. I've made all Keying Sets fallback to adding as if they were local for now, but a better solution is coming soon.
* Fixed a typo in RNA function wrappers for the generator callback, since it was looking for the iterator only. This doesn't seem to have caused any problems (thankfully).
