Integer scaling is achieved (after aspect expansion) by "lying" to the
stretching code about the window's size, telling it that it's always an
integer multiple of the viewport so that it only gets stretched to an
integer factor.
This approach works with all stretch and aspect modes and doesn't
require handling for each, only requiring to "loosen up" some
self-excluding conditions (in other words, replacing some `else if`s
with just `if`s) regarding viewport offset and margin calculation (black
bars).
Includes a tiny usability change that adds a range hint for the content
scale factor between 0.5 to 8.0.
Co-Authored-By: Hugo Locurcio <hugo.locurcio@hugo.pro>
This allows the user to input numbers during an "instant" (blender
style) transform operation to specify exactly how far to transform the
object. For example:
g2.5xx: Translate 2.5 units along the local x-axis
ry-45: Rotate -45 degrees around the y-axis
s.25Z: Scale by a factor of .25 on the xy plane
Some shared code between the traslate/rotate/scale branches of update_transform
was refactored into apply_transform so numeric transforms could reuse it.
This removes any "{X,Y,Z}-Axis Transform" messages. These prevented the
"Transforming: (x,y,z)" messages from showing, and the latter are more
useful, as they tell you the actual units.
This also rearranges finish_transform to clear _edit before updating
the axis rendering, so an axis doesn't remain highlighted.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
Fixes#67287. There was a subtle error where due to how enabling motion vectors for multi-meshes was handled, only the first instance would have a valid transforms buffer and the rest would point to an invalid buffer. This change moves over the responsibility of enabling motion vectors only when changes happen to the individual 3D transforms or the entire buffer itself. It also fixes an unnecessary download of the existing buffer that'd get overwritten by the current cache if it exists. Another fix is handling the case where the buffer was not set, and enabling motion vectors would not cause the buffer to be recreated correctly.
Previously for InputEvents there was no distinction between
Window-area and Viewport-area.
This was problematic in cases where stretching was used and the Window
contained black bars at the sides of the Viewport.
This PR separates the area of Window and Viewport regarding InputEvents.
Firefox will always report the user's GPU as a GeForce GTX 980 in
an attempt to make fingerprinting more difficult.
This is not the case in Chromium-based browsers though.
