So that users opening a .blend saved in 2.70.5 and above in an older version
get warning the file might not be 100% compatible (should have been done
already for 2.70, actually).
Editing the y-coordinate of the right handle of a keyframe via the Active Keyframe
panel in the Graph Editor, while both handles are selected and are both of type "aligned"
resulted in weird behaviours such as the x-coordinate of the right handle changing
(and rapidly starting to overshoot) but nothing else. However, this problem
doesn't occur when only a single handle is selected.
It turns out that the "order of computation" logic in calchandleNurb_intern() gets
confused in the case of both handles being selected, and results in a sub-optimal
handling of the right handle being the one that's been changed. We hack around this
here by temporarily making it so that just the right handle is selected when doing
the updates here.
With the right handle selected, the movement of the left handle appears constrained
to the frame it is currently on, leading to unpredictable and wild overshoots of the
bezier curve. There appears to be little benefit in doing so.
The effect of this patch is that makes it so that instead of trying (initially) to
maintain the same distance between the two handles and then overshooting randomly
later, the handles now try to keep the same distance from each other (i.e. similar
doing a rotation around the keyframe) at all times. While this means that it isn't
possible to set up assymetric handles (i.e. where ease in to the key is less than the
ease out for example) using aligned handles (it's still possible using free; it's just
a lot more work to keep them aligned), the benefits of removing of the random blips and jumps
when things jump outweight the losses.
Patch by Brecht
This patch adds icons for each of the keyframe interpolation types (including
the easing equations), as well as icons for the easing type options.
Icons made by: Paulo José Oliveira Amaro (pauloup)
Reviewed by: Joshua Leung, Thomas Beck
This adds some view ratios in the video sequencer menu, based (copied) on the UV/Image Editor. It also fixes the inverted ratio issue reported in the same task.
Reviewers: #video_sequencer, #user_interface, schlaile
Reviewed By: schlaile
CC: jta, dingto, sergey, schlaile
Differential Revision: https://developer.blender.org/D447
* Buffer icons are usually in straight space (since we load from pngs)
so use src_alpha in OpenGL for blending.
* Allow blending for preview icons. This will be useful for the next
commit...
Make RNAPointer props un-editable here, we simply cannot handle this.
Also correct previous commit, asking for autonaming for all items was a bit extreme,
this is only needed for enums!
Broken enums widgets was a sequel of rBe5e0888a8f02 (when we want auto-naming,
we have to pass NULL, not and empty string!).
Now remains the RNApointers issue...
Text field part. Issue with enums dropdowns remains a mystery currently.
As for pointer fields, afaict they have never worked here, though it should
not crash.
UI_EMBOSS are values, not bitflags (own fault, most likely)...
Note we should probably get rid of UI_EMBOSST, it is used nowhere in UI code (set
in one place only, used nowhere).
This change makes lighting in GLSL preview more accurate, though it still
doesn't support material's "Exclusive" option.
Technical note: Changes in view3d_draw.c are not essential, these avoid
preparing unused shadow buffers.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D457
Made the timeline option to only show keyframes from selected channels/data be a
per-scene setting instead of the per-timeline option it was previously. This makes
it easier for animators working on rigs with multiple bones (especially during the
polishing phase), since now the timeline and jump to keyframe operators use the same
setting to decide which subset of keyframes they need to consider.
By default, this option is enabled by default.
TODO: Extend this to the keyframe status shading on the active object name in the 3D view?
Note it was already the case for many simulations (cloth, rigidbody, etc.), just doing this
systematically in BKE_ptcache_add() now, will avoid us some recurring bug reports.
Advanced users will know when they can/have to raise this parameter!
In fact, armature layers operators (set layers, and show all) were kind of messy and broken
in Edit mode (Select layers had two different operators for Pose and Edit modes, both
using the same funcs that could only work in Pose mode, Show All was supposed to be
used in both modes but again, its exec code could only work in Pose one).
Fixed that by:
* Using only one op for each task, for both modes (with adapted poll func).
* Replacing 'object from context' access by an helper that returns the right Armature
object in both Edit and Pose modes.
This issue is because of a somewhat "special" behavior in old code, which got lost during rB09874df:
There was a variant of the `relinkConnections` function which would leave the socket completely unconnected. This is not a valid state really (given that each unconnected input must otherwise connected to a constant `Set` type node), but was used as a way to distinguish connected alpha/depth sockets in composite and viewer output nodes.
https://developer.blender.org/diffusion/B/browse/master/source/blender/compositor/intern/COM_InputSocket.cpp;28a829893c702918afc5ac1945a06eaefa611594$69
After the large cleanup patch ({D309}) every socket is now automatically connected to a constant, such that `getInputSocketReader` will never return a NULL pointer. This breaks the previous test method, which needs to be replaced by more explicit flags. Luckily this was done only for very few output nodes (Composite, Viewer, Output-File). These now use the regular SetValueOperation default in case "use alpha" is disabled, but set this to an explicit 1.0 value instead of mapping to the node socket.
Since autosnap was being applied during the flushing step for various practical reasons,
it wasn't possible to restore keyframes and handles to their original values, as these
would always get overwritten before getting a chance to be written back to the keyframes.
