Blender Git Commits

Fix T93367: wrong attribute propagation in Delete Geometry node

This only happened with non-point selections. It used an incorrect
index mapping for the attribute propagation.

Merge branch 'blender-v3.0-release'

Fix T93362: crash when capturing attribute after fillet curve node

The issue was that the attribute propagation in the Fillet Curve node seems
pretty broken. I couldn't really make sense of the old code. It changed the
size of the point attribute domains on splines to 1 for some reason which
led to a crash in the next node.

Differential Revision: https://developer.blender.org/D13362

Merge remote-tracking branch 'origin/blender-v3.0-release'

Fix T93321: Modified Mirror modifier behavior break some other tools like bound SurfaceDeform.

Revert "Fix T91444: Edge Loop Preview fails with two Mirror Modifiers"

This reverts commit 1a7757b0bc6945ab7d3b281f3e0dd7130bcf80f0.

Caused issue reported in T93321, boiling down to the fact that other
operations or modifiers (like the SurfaceDeform one) rely on the order
of the vertices in the mesh to remain consistent.

Changing this in a modifier would mean those operations need to be
reset/re-created (e.g. rebound for the SurfaceDeform case), which is not
doable in `do_version` code.

Fix T91444: Edge Loop Preview fails with two Mirror Modifiers

The mirror modifiers merge option caused unnecessary re-ordering
to the vertex array with original vertices merging into their copies.

While this wasn't an error, it meant creating a 1:1 mapping from input
vertices to their final output wasn't reliable (when looping over
vertices first to last) as is done in
BKE_editmesh_vert_coords_when_deformed.

As merging in either direction is supported, keep the source meshes
vertices in-order since it allows the vertex coordinates to be extracted.

NOTE: Since this change introduce issues for some cases (e.g. bound
modifiers like SurfaceDeform), this change is only applied to newly
created modifiers, existing ones will still use the old incorrect merge
behavior.

Reviewed By: @brecht

Maniphest Tasks: T93321, T91444

Differential Revision: https://developer.blender.org/D13355

Fix T93155: Approximate shadow catcher displayed wrong on CPU and GPU

Was happening during rendering, causing visual artifacts when doing
CPU+GPU rendering, and giving different in-progress results on different
devices.

The root of the issue comes to the fact that math used in the approximate
shadow catcher calculation might have resulted in negative alpha channel,
and negative values for display are handled differently on CPU and GPU.
Such difference in handling is caused by an approximate conversion used on
the CPU for the performance reasons.

This change makes it so no negative alpha is generated by the approximate
shadow catcher. Not sure if we need some explicit clamping somewhere to
deal with possible negative values coming from somewhere else.

The shadow catcher cornell box tests are to be updated for the new code,
but the new result seems to be more accurate.

Differential Revision: https://developer.blender.org/D13354

Merge branch 'blender-v3.0-release'

Fix Py API: wrong doc about type of Collection property.

Collection property only accepts PropertyGroup type, not ID ones.

Reported on IRC by @frameshift, thanks.

Merge branch 'blender-v3.0-release'

Fix black Cycles result when cancelling tiled rendering with shadow catcher

Noticed when was looking into T93155. Steps to reproduce:

- Open the .blend file from the report
- Hit F12 to start rendering
- After some tiles were rendered hit Esc

The issue is caused by "sticky" cancel reported via Progress. This means
that once user hit Esc all further requests for cancel state will return
truth, which was preventing OIDN denoiser from completing the denoising
task.

Now only allow stopping the denoiser when interactive rendering requests
a very fast stopping.

Aiming the fix for 3.0 branch.

Differential Revision: https://developer.blender.org/D13352

Merge branch 'blender-v3.0-release' to bring in D13042:
Fix performance decrease with Scrambling Distance on

Fix performance decrease with Scrambling Distance on

With the current code in master, scrambling distance is enabled on non-hardware accelerated ray tracing devices see a measurable performance decrease when compared scrambling distance on vs off. From testing, this performance decrease comes from the large tile sizes scheduled in `tile.cpp`.

This patch attempts to address the performance decrease by using different algorithms to calculate the tile size for devices with hardware accelerated ray traversal and devices without. Large tile sizes for hardware accelerated devices and small tile sizes for others.

Most of this code is based on proposals from @brecht and @leesonw

Reviewed By: brecht, leesonw

Differential Revision: https://developer.blender.org/D13042

Merge branch 'blender-v3.0-release'

Fix T93357: crash when opening search menu

This is the same fix as in rBde35a90f9f56d3ff3ac80c13bf1ae296853ba877
but for the blender-v3.0-release branch.

Fix T92962 Boolean output indices unstable.

A parallel loop to create the interesection meshes for each triangle
meant that with parallelism, the output order of the created meshes
could vary with each execution. Keep the parallelism for doing the CDTs
for interesection, but move the extraction of the new faces into a
serial loop afterwards, for repeatability.

Merge branch 'blender-v3.0-release'

UI: Improve scaling of widgets when zooming

This commit improves the scaling of some ui widgets when
zooming by making the radius of the rounded corners
dependent on the element's zoom level.

Needed to fix T92278 without padding issues, see D13125.

Reviewed By: Hans Goudey, Julian Eisel

Differential Revision: https://developer.blender.org/D12842

Merge branch 'blender-v3.0-release'

Fix T90808: wrong BoundBox after undo curve selection

There are two functions that recalculate the boundbox of an object:
- One that considers the evaluated geometry
- Another that only considers the object's `data`.

Most of the time, the bound box is calculated on the final object
(with modifiers), so it doesn't seem right to just rely on `ob->data`
to recalculate the `ob->runtime.bb`.

Be sure to calculate the BoundBox based on the final geometry and
only use `ob->data` as a fallback

Differential Revision: https://developer.blender.org/D12282