Before this change only old flag "Premultiply" was used to
detect alpha mode, which is not enough actually.
Now the logic here is:
- If "Premultiply" was enabled it is likely float image with
straight alpha, which shall be premultiplied before usage.
In this case image/sequence Alpha Mode is set to Straight.
- Otherwise use default alpha mode for image format based on
an extension. This could fail in some cases like TIFF, but
this wasn't handled fully correct in older blender anyway.
Initial discovered issue was that EXR images saved in older
Blender versions were set to Straight alpha mode, which is
obviously a straight way to lots of headache.
edit mode
My earlier fix for [#33974] (in r.54061) was causing some problems where
manually specified roll values on horizontal or angled bones were getting reset.
This could be nasty as you might not notice the changes for a while (especially
when using stick bones without axes displayed).
I've now put in place a hacky compromise solution which should catch both of
these situations nicely. For z-axis (i.e. vertical) movements, the r.54061 fix
is used, while for everything else (moving or just touch-n-go), the old setting
is used.
This was caused by a floating point precision error. During collision detection, Newton-Raphson iteration is used to find the exact time of the collision. But when using subframes, the initial Newton step was too small. Now the initial step is given in absolute units. When subframes = 0, this should behave almost the same as before.
Thanks to Janne Karhu, Lukas Toenne and Ton Roosendaal for their help with this patch, and to AutoCRC for funding.
Now, disabled items use a mix of text and menu item background (inner) color. Same results, but allows dark themes with bright selected text to use shadows.
Example case: http://pasteall.org/pic/show.php?id=45697
alpha was used for them which doesn't work for cleaned footage stored
in EXR file format.
Perhaps we need to support configurable alpha mode for clips, but
that's for later (maybe even after release),
CTRL + MMB zoom in 2d editors now depends on 'max zoom' level. This makes
zooms in UI (very limited) go smoother, but for fcurve or timeline it's same.
with transparency, would show as too dark colors on edges.
Found a strange issue here though, the alpha value in the OpenGL render result
is not the same as the one specified in the material. It's not clear to me why
this happens, color space conversions should not influence the alpha channel.
Right now most simulations can't handle cache start frame < 1
unfortunately.
There are two main problems:
1. frame 0 is a special case so some simulations will just pop back to
their initial state on frame 0.
2. blender doesn't allow playing the animation starting from negative
start frames, so most simulations only work when baked and not during
regular playback.
Just change soft limit since sart frame < 1 can work in some cases, but
this needs to be fixed properly in the individual simulations if we
really want to allow it.
Grid was blending with wrong theme color.
Since r53636 TH_HIGH_GRAD is used as a background and this
color shall be used for blending.
This is possible other usages of TH_BACK are wrong here as
well, but would want Antony to check on this.
Systematically adding some custom id to template_list using default UI_UL_list class, this one is commoly used more than once in an area, yielding collision issues if they do not have a custom id...
libmv still requires optimization switched off because
of some incompatibility of SSBA and MSVC optimizer which
makes bundle adjustment work just wrong.
This shall not be an issue for Ceres and no need to
disable optimization for extern_ceres
Calculate dependent area based on distortion model rather than
using 15% of image resolution for this.
Some assumptions here:
- We're assuming real-life camera calibration is used here
- Maximal undistortion delta would be achieved on frame boundary
- Distortion fully goes inside frame
This makes it possible to approximate margin for distortion by
checking undistortion delta across frame boundary and use it
for dependent area of interest.
We do not use any formula-based equation here because we're likely
support other distortion models and in that case it'll be stupid
to try detecting formula here.
This fixes a bug in sequencer cut tool:
* if you cut two strips of the same name class (MVI_XXXX.MOV and MVI_XXXX.001)
the two new generated strips will end up with the same name.
(easy test case: add a MOV file with it's accompanying audio track to the
timeline and then cut both strips at once into two pieces)
* visible problem: your animation data will get messed up on the way, since
the animation system doesn't know, which strip it should assign the
animation.
Problem was caused by generating a new list of sequences within the
cut_seq_list() function:
Since dupli_seq() can't see the members of the new list of sequences, it
won't be able to assign unique names in all cases.
The RNA path interpretor code was using a function to get the portion between quotes,
this function was not even checking if there *are* quotes at all! Causing bad
memory allocs or crashes.
Also enhanced the ugly py ast parsing code, so that it now can handle (up to some extent) "name" function nodes, and add bpy.app.translations.pgettext func familly to extracted ones...
This ast py parsing becomes more and more ugly, should probably try to refactor it a bit. :/
