This works by using the distance in the x axis only (usually artists want to influence nearby
keyframes based on timing, not value). Tweaking handles is the same as tweaking
the central handle. It's a bit ambiguous if proportional editing is really meaningful
for handles but will leave that for artists to decide.
The issue has been here since we changed drawing code for meshes to use
vertex arrays instead of immediate mode when VBO was off. Basically we
should now always invalidate the GPU objects regardless of the VBO
setting in the preferences.
The bug has been there since 2.73 at least, but what made it apparent
now is that new version resets preferences and as an extension the VBO
flag.
Should be included in final 2.74 release
Typical error using '->next' member of a freed linked list item. A bit trickier
even here, since we have some recursion...
Trivial fix for nasty crasher, safe for 2.74 imho?
The return type of raise_exc_wheel() is bool, but the method return -1. The compiler will change the return type type to an int. This can cause some problems on 64bit systems.
Reviewers: lordloki, sybren
Reviewed By: lordloki, sybren
Differential Revision: https://developer.blender.org/D1204
ATI driver does not like declaration of gl_FragColor and glFragData in
the same source file (even though only one of the two is ever
referenced), just use one of the two.
and on screen rendering.
Aaaaah, the beauty of driver implementations of OpenGL!
Turns out the problem here is that drivers calculate df/dy differently
in some cases (probably because OpenGL counts y reverse to how the
window system does, so drivers can get confused).
Fixed this for the ATI case based on info we have so far, there's also
the Intel case which will be handled separately (missing info on Intel's
renderer string etc).
Unfortunately we can't really fix this for the general case so we'll
have to haldle cases as they come in our tracker and by adding silly
string comparisons in our GPU initialization module <sigh>.
Still not ideal but getting closer. Main annoying thing so far is
dependency of Render structure for now. It is used to switch particles
to render mode and could probably also be eliminated.
* Insert Keyframe tool for Dopesheet/Graph Editors needed to be modified to
not try to resolve the paths for NLA Control Curves
* For now, the poll callback to get the "Active FCurve" also works when given
a NLA control curve. They're really the same in most cases, and this should
be fine until one of the channels does something funky.
* Clicking anywhere on the expander collapses it (like for the gpencil one)
* Deleting these curves works now (but has the side effect of turning off
the animated influence/time options too, as it is assumed that when those
are enabled there is a corresponding fcurve)
Using the standard "FCurve" animchannel type didn't work that well for
the control FCurves on NLA Strips, as the paths would not resolve correctly,
and the indentation was wrong. Also, there would likely be issues down the
track with applying NLA mapping. Hence, it's easier to just create a separate
type for this case, and adapt the rest of the code to also consider these (todo).
The "Nla Strip Controls" channel is used to house the per-strip
FCurves for controlling the strip_time and influence properties.
It sits above the active action's first group, at the same level
in the hierarchy as other groups.
TODO: It looks like a dedicated FCurve channel is needed for these
control FCurves, so that we won't accidentally apply NLA mapping
or have these FCurves disabled by the path lookups failing.
Reshuffled order that in which NLA Strip's F-Curves vs its automatic settings are
evaluated so that the automatic settings can always override the custom settings,
since it's not that easy to get things working correctly the other way around.
