When the dopesheet was open, "keyframe edited" events from the graph editor
(i.e. fired whenever any properties on keyframes or FModifiers are changed)
would trigger the dopesheet to synchronise selection states of anim channels
and ensure that FCurve autocolours are initialised correctly.
This however was undesired when editing properties in the graph editor. Now,
made it so that keyframe adding/removing operators use different notifier flags
to specify that the channels might have changed + need colour syncing, and
adjusted the dopesheet updating logic to fit
libraries view not working.
This was disabled in the operator, there may have been a reason for this at
some point, but I can't see any reason to disallow it in the current code or
find a good reason why it was done in the commit logs.
This makes a number of operators no longer ask for confirmation, rather it will
show an info message after performing the operation. Ref T37422 for decision. In
particular, these were changed:
* Delete objects, bones, keyframes, masks, mask curves, motion tracks, markers.
* Clear and delete keyframes in the 3D view.
* Align bone to parents.
* Separate bones from armature.
* Group/ungroup metastrips in sequencer.
* Copy/paste objects to/from buffer.
Reviewed By: brecht, dingto
Differential Revision: http://developer.blender.org/D35
Remove KeyMap mode from outliner, was an old half-finished features redondant with user preferences settings...
Also moved key map item's "event type to map type" and map type defines at WM level, this is too much generic to be at RNA level.
Also added a check in versionning code to convert all outdated outliner modes to a valid one (seems old 'verse' ones were not handled as well).
Thanks to Brecht for reviews and advices!
This means that it will no longer be possible to accidentally load a nodetree action in
the Action Editor (object-level actions only), resulting in F-Curves getting
invalidated/disabled.
* 'Show Debug' now enabled for all newly created drivers. For most users, it is
useful to be able to see this to help figure out what's going on
* Removed failed experiment of creating new drivers with Generator FModifiers. I
had hoped that this would make it easier to create drivers that doubled or
halved the input values, but that has proved to not be the case, and instead
made harder for most users to set things up (as they'd have to remove these
first).
Now, when adding drivers from the UI, these get created with two keyframes (at
(0,0) and (1,1) for a 1-1 mapping), which can be easily tweaked normally.
However, for backwards compatability of scripts (notably rigify, and perhaps
some others out there), when creating drivers from scripts, they will still get
created with Generator FModifiers for now. We can review this situation again
for 2.7, but for now it seems ok.
using "Auto Keying" + "Insert Available Only"
Patch from Campbell.
The problem was that NLA offset/mapping correction was only done when no
destination action was supplied to insert_keyframe(). In most cases, this is not
a problem, since all normal keyframing goes through keyingset or the insert-
button operators, and these just pass action=NULL (since they're too lazy to
look it up). However, there is one situation where this bug gets triggered (the
specific combination of autokeyframing and "insert available only"), where the
caller of insert_keyframe() actually passed in an action (to prevent it from
creating one itself!).
Most of the places which relied on RNA_path_resolve() did so believing that if
it returned true, that it had found a valid property, and that the returned
pointer+property combination would be what the path referred to. However, it
turns out that if the property at the end of the path turns out to be a
"pointer" property (e.g. "data" for Object.data), this would automatically
become the pointer part, while the prop part would be set to null. Hence, if a
user accidentally (or otherwise) specifies a path for the single-property driver
variable type like this, then Blender would crash.
This commit introduces two convenience functions - RNA_path_resolve_property()
and RNA_path_resolve_property_full() - which mirror/wrap the existing
RNA_path_resolve() functions. The only difference though is that these include a
check to ensure that what was found from resolving the path was in fact a
property (they only return true iff this is the case), and make it explicitly
clear in the name that this is what they will do so that there's no further
confusion. It is possible to do without these wrapper functions by doing these
checks inline, but the few cases that had been patched already were pretty
hideous looking specimens. Using these just make it clearer and simpler for all.
I've also beefed up the docs on these a bit, and changed these to using bools.
Fix for keyingsets tips, and make them (and a few others) findable by i18n messages extracting code (for some reasons, their bl_rna.description are void???).
Big thanks to Josef Meier (jomeier) for finding the fix!
It turns out that this was a case of variable shadowing that had been overlooked
and compilers were not warning about.
besides performance in some cases.
* DAG_scene_sort is now removed and replaced by DAG_relations_tag_update in
most cases. This will clear the dependency graph, and only rebuild it right
before it's needed again when the scene is re-evaluated.
This is done because DAG_scene_sort is slow when called many times from
python operators. Further the scene argument is not needed because most
operations can potentially affect more than the current scene.
* DAG_scene_relations_update will now rebuild the dependency graph if it's not
there yet, and DAG_scene_relations_rebuild will force a rebuild for the rare
cases that need it.
* Remove various places where ob->recalc was set manually. This should go
through DAG_id_tag_update() in nearly all cases instead since this is now
a fast operation. Also removed DAG_ids_flush_update that goes along with
such manual tagging of ob->recalc.
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
