There was an error in the other branch of the refactored function where the size of the array was not properly multiplied by the size of the float to check against the buffer size. This was only an error in the error-checking itself and not the functionality. There was also an error where the proper notification was not emitted whenever the buffer for the multimesh is recreated to invalidate the previous references the renderer might've created to it. This fixes CPU Particles getting corrupted when they're created without emission being enabled.
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.
