The function to get a list of markers was not clearing the list before it exited
early, and with no way to tell that the method failed, callers could make the
mistake of trusting that the list was now valid (i.e. either full of marker
frames or empty, vs being invalid)
From the various forum threads and the fact that a new addon has cropped up,
it appears that it is not that well known that this tool exists, and that it
can be used solve a very common problem that animators face. Namely:
When you've gone through blocking out your key poses and then realise
that you need to adjust parts of the rig which don't change much, this
tool solves the problem of needing to go through doing grunt-work to
fix all the other keyframes which now need to change as well.
So, this tool is now available in the following two places (in addition to
the existing Pose -> Propagate menu):
* Toolbar - The "Propagate" button will use the default mode (or the last
used mode for each subsequent invocation).
The arrow-button beside this will allow choosing between the different
modes. (NOTE: The UI team may have different thoughts on this, but,
let's give this a try for a while first, to see if this sort of thing works)
* Alt-P - In Pose Mode, this will now bring up a menu allowing you to choose
which mode is used. Since this sort of thing is something that does
get run several times in a row when you need it, having this hotkey
will make it a bit more convenient.
This commit adds a new mode for the Propagate Pose tool. With this new option,
the Propagate Pose will copy the current pose over to all selected keyframes
after the current frame.
For reference, some of the other/existing options are: to copy it to each subsequent
keyframe with the same value (WHILE_HELD - the default), to the next keyframe,
or to the last keyframe.
When in Stroke Edit Mode, an indicator/warning message is now shown in the top-right
corner to make it easier to notice that operations will apply to Grease Pencil
strokes instead.
* Moved the context handling stuff into gpencil_utils.c
* Moved the datablock and layer operators out into their own file too. Again,
these weren't related to the other stuff that much
* Split the GPencil to Curves operator out into its own file (gpencil_convert.c).
This was quite a massive blob of code (48kb) that was not that related to the
other operators still in that file (gpencil_edit.c)
Caused by changes in 31e26bb83b. This makes it fall back to the old
method if we can't find a screen.
Patch is actually by @LazyDodo with minor edits by me.
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?
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.
