`applyResize(...)` considers that `t->values` always represents a `ratio`.
But this is only `true` with the `MOUSEMOVE` event.
The solution proposed is to never change `t->values`.
The result of the final transformation is now written to `t->values_final`.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D5212
While these aren't currently used, its strange to have
extended versions of a function without the non-extended versions
it also avoids callers needing to add them back if they need -
or duplicating the same boiler plate when calling the '_ex' versions.
Reverts 11da3b132a, 11da3b132a, adds depsgraph argument
so the caller is responsible for the evaluation state.
There were several problems in the old random calculation:
* Different result in the viewport and render.
* Noise "pop" in some frames.
* Random number was calculated every time the file was opened, so get different results.
Now, instead to calculate the random numbers when n number of frames changed, the random values are calculated using a unique seed by stroke.
Also, a new Seed parameter has been added and this adds more control in the noise generated. This value can be animated and get more variations.
Differential Revision: http://developer.blender.org/D5393
Meshroom writes two hierarchies to Alembic, one rooted at
`/mvgRoot/mvgCameras` and the other at `/mvgRoot/mvgCamerasUndefined`.
These paths have no schema definition, and thus are ignored by Blender.
The cameras themselves have those schemaless paths as parent, and have
their transforms marked as "inherited", e.g. relative to their parent.
As these cameras have no valid parent, there is no Blender object to use
to convert their local matrices to world matrices, and Blender just
decided to reset them to the unit matrix.
Now "inherited" transforms without a parent in Blender are interpreted
as world transforms. Reparenting those objects to a Blender object will
re-interpret the transforms as local to the parent again.
FFmpeg expects Blender to feed it pixels in the output pixel format. If
the output pixel format is different than Blender's RGBA, a conversion
is needed (via FFmpeg's `sws_scale()` function). There were a few issues
with this conversion (and surrounding code) that are fixed in this
commit:
- When conversion was necessary a temporary buffer was allocated and
deallocated for every frame. This is now allocated once and re-used.
- Copying data to the buffer was done byte-for-byte. On little-endian
machines it is now done line-by-line using `memcpy` for a little speedup.
- The decision whether pixel format conversion is necessary is now
correctly done based on the pixel format Blender is actually using.
- The pixel format of the buffer sent to FFmpeg is no longer hard-coded
incorrectly to a fixed pixel format, but uses the actual output pixel
format. This is fixes T53058 properly, making RGB QTRLE export possible.
- I added some comments to make it clear which pixel format is referred
to (either Blender's internal format or the FFmpeg output format).
Combined these improvements not only correct a bug (T53058) but also
results in approximately 5% speed improvement (tested with a 117-frame
shot from Spring, loaded as PNGs in the VSE, encoding to h.264 with
preset 'realtime').
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D5174
We no longer build with or support msvc2013, so this hack can be removed.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5298
The problem is that the `glDrawArraysInstancedBaseInstance` is ignoring the last parameter.
The solution is to indicate that `GLEW_ARB_base_instance` is not supported in these cases.
Reviewers: fclem, brecht, jbakker
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D5383
This adds a space between a value and its short unit name except for foot, inch, degree, arcminute, arcsecond
Differential Revision: https://developer.blender.org/D5051
Reviewed by Brecht Van Lommel
At least one script writer was upset that this was not specified,
as it is different from "floating point" in Python.
Also, docstring for hard and soft min and max for FloatProperty
was wrong, using sys.float_info.min and sys.float_info.max.
This reverts commit 7761657129.
This commit broke overlapping popovers. For example in the color
management tab it would be impossible to select and of the popover
alternatives as it would switch to the menu button under the cursor.
Was a nice looking invention, but is obviously wrong.
Is likely no function changes, since -false is like -0
which is 0 and which false. And -true is like -<non-zero> which
is non-zero as well.
Spotted by Sybren, thanks!
We would not take into account the user "Zoom Axis" setting in certain
2D space viewports. In addition to this, the "Scale Zoom" didn't work
consistently in these spaces either.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5132
