Caused by 2df06a05ae
totobj and selected objects are not counted for sculpt mode stats (can
do that but it's unnecessary). Hence the above commit falsely showed 0
objects in statistics. To fix this, skip showing object count in sculpt
mode, otherwise print 0 objects if selobj and totobj are none.
Pull Request: https://projects.blender.org/blender/blender/pulls/120106
Seems to be caused by c53e220aef. I didn't think our PBVH building would
ever create a node with no triangles, but I guess I was wrong, since I
checked and the PBVH is clearly being rebuilt after the trim operation,
so it seems there isn't anything else weird going on here.
Rather than trying to figure that out, I'll just add the empty check
back here. Eventually we should completely replace the algorithm that
creates the PBVH nodes anyway.
The root of the issue seems to be calling `BLI_snprintf` with the
wrong number of arguments in the `MorePointsForBezierRequired`
case. The fix arguably makes things simpler anyway: just use a
separate call in each case of the switch.
This PR completes coverage of the event icons used to represent keymap
entries on the status bar. This adds 0-9, non-alpha keys, tablet, F13-
F24, NDOF buttons, etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/120117
Adjustments to the spacing of keymap items shown in the status bar
while idle and during modal operators. Decreased space between icon
and related text makes each item have better separation.
Pull Request: https://projects.blender.org/blender/blender/pulls/120124
When the cage mesh is the output of a modifier that supports deforming
BMesh directly, it will be a mesh wrapper and `MR_EXTRACT_BMESH` will
be used. Otherwise the cage mesh will be a `Mesh` and its own normals
should be drawn instead of the the original normals. Thought this seems
deceivingly simple, it works with no modifiers, BMesh-deforming modifiers
with cage enabled and disabled, and topology changing modifiers, which
should be all the possible cases here.
Set the w component to 1 in Float to Vector implicit conversion for the
Realtime Compositor. That's because the Vector Output node expects a
vector for the velocity input, but the CPU compositor fakes it as a
color input, while assumes a fourth component of 1.
The property name can contain `"` which would cause keyframing to
fail. By escaping it those properties can now be keyframed.
E.g. property names like `"test"` now properly receive keys.
Pull Request: https://projects.blender.org/blender/blender/pulls/119922
Creating the batch cache for rendering crashes when
there is a stroke with one point that is set to cyclic.
There was a missing check for the number of points
because we're accessing the curve lengths, which
needs at least 2 points to be populated.
In `process_stroke_end`, an end point that has a thickness of 0 will be
removed, but the `IndexRange` for points isn't updated, leading to wrong
slicing downstream.
Pull Request: https://projects.blender.org/blender/blender/pulls/120165
ffmpeg AVFrame objects should use correct alignment between image
rows, or otherwise bad things might happen. In this particular
case, multi-threaded libswscale RGB->YUV conversion was trampling
over 4 bytes of V plane, for each thread boundary.
Pull Request: https://projects.blender.org/blender/blender/pulls/120168
Retain the alpha channel in Color to Vector implicit conversion for the
Realtime Compositor. That's because speed passes are exposed as color
sockets, so connecting them to a node like Vector Blur will lose the
y component of the next vectors.
The CPU compositor handles that by faking vector sockets as color
sockets internally, while the realtime compositor does not do that.
As in the Linux case, it seems like the atomic rename doesn't work on all file systems on Mac either.
We did test on Windows and it seems like there is a built in fallback, so we don't need to do this there.
Pull Request: https://projects.blender.org/blender/blender/pulls/120037
For some reason, the custom data type was set as `float[4][4]`
for tangents, but they are written as `float[4]`. The overallocation
might not have been a problem, since it looks like the extra memory
was never written to. But it's still confusing and potentially bad for
performance.
Previously the bounds were accessed on the original object.
That used to implicitly get the evaluated geometry's bounds,
but now that is an explicit choice.
Since the code was added, it used the active indices of the input and
output custom data layers incorrectly. 82b88f130a exposed that
by actually modifying the active indices of the ouput custom data
correctly, but it didn't update a couple other places to take that into
account.
The functionality of snap with constraints relies on the position of
the transformed object.
Previously, snap to grid with constraints was restricted to the Move
operation.
Consequently, the 'Set Snap Base' mode, as well as other transformation
modes, failed to compute the moved position.
As a result, it lacked support for snap to grid with constraints and
would even crash under such circumstances.
The solution involves eliminating the reliance on the Move operator and
instead calculating the position based on mouse position.
The Vector Blur node sometimes produces wrong output. That's because no
proper memory barriers existed for the SSBO written to by the velocity
dilation pass, so ensure a proper barrier exist.
The Vector Blur node has blocky artifacts. That's because one of the
buffers used in the velocity dilation pass was not zero initialized,
while it was written to using atomic max operations, so make sure it is
zero initialized.
While valid, this isn't so common and cppcheck warns about this,
use explicit casts to suppress the warning, also correct "true"
being assigned to a float value.
One copy_v4_v4 call was used to initialize both camera_uv_scale &
camera_uv_bias, replace this with 2x copy calls since passing in
smaller buffers to copy functions is typically an error.
