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.
fdc2962beb indirectly introduced a change
in inlining (light_tree_pdf started getting inlined) that led to a 5-10%
drop in performance for most scenes.
Dropping the noinline keyword for oneAPI device recovers it.
It however brings another performance regression to MNEE and Raytrace
kernels, that we'll look into separately.
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
The python script checks on reports based on the provided severity (default High) and sorts them per module.
Thanks to Sybren for suggestions on how to improve it!
Pull Request: https://projects.blender.org/blender/blender/pulls/120022
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
The script to run cppcheck failed for most files in source/ because
of a syntax error in MEM_guardedalloc.h with attribute functions.
Workaround the error by including BLI_compiler_attrs.h directly.
Other changes:
- Specify c++17 / c11 standards for C++ & C.
- Resolve errors from undefined integer ranges.
- Set the check level to exhaustive so checks always run.
- Suppress noisy missingIncludeSystem warning.
- Move run-time compiler defines into a temporary include
which resolves argument quoting errors when cppcheck is used with
clang's parser.
While an empty string resolves to the default theme, it's not following
the API specification for wl_cursor_theme_load as it's written.
Checking on wayland internals this looks only to add an unnecessary
theme lookup on an empty string which falls back to the default.
Noticed when investigating #105895 although it seems unlikely
that this chagne would resolve the issue.
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.