Blender Git Commit Log

Fix T92609 Default Compositing tab shows red overlay when stereoscopy is turned on

This was caused by the drawing not being done on the right frammebuffer.

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.

GPUShaderDescriptor for interface abstraction

This is a first draft of what the Shader Descriptor system could be.

A shader descriptor provides a way to define shader structure, resources
and interfaces. This makes for a quick way to provide backend agnostic
binding informations while also making shader variations easy to declare.

- Clear source input (only one file). Cleans up the GPU api since we can create a
shader from one descriptor
- Resources and interfaces are generated by the backend (much simpler than parsing).
- Bindings are explicit from position in the array.
- GPUShaderInterface becomes a trivial translation of enums and string copy.
- No external dependency to third party lib.
- Cleaner code, less fragmentation of resources in several libs.
- Easy to modify / extend at runtime.
- no parser involve, very easy to code.
- Does not hold any data, can be static and kept on disc.
- Could hold precompiled bytecode for static shaders.

This also includes a new global dependency system.
This is a prototype to support `#include` directive inside glsl sources.

I went for a C type shader description with static array for the given reasons:
- Simplicity: this is compiled language, can be extended at runtime by
C and C++ without much effort, no parsing involved.
- Readability: Can use designated initializers which allow meaningful
syntax (like `.push_constants` or `[0]` for the 1st bind point).
- Combinations: We can combine descriptors to create shader variations
really quickly. See `workbench_prepass.desc.h` in the branch for some crazy combination.
- Avoid having to write a C++ interface for C usage.

Note that the CMake changes are just to make things work.

What is remaining:
- GL backend to generate uniforms and support push constants (via uniforms).
- pyGPU API

What I would like to discuss:
- Naming: Is "descriptor" too much similar to vulkans descriptors set? This might create
confusion. Maybe MetaData is better? But it may hold more than meta data.
- Choose the right extension for descriptor files.
- Choose the right folder. Do we keep them alongside shader files even if name could differ?
- Indentation is 4 spaces for some reasons in descriptors definitions.
- Memory usage might be a concern. We are talking about ~3 MByte of data in the executable.
- Syntax: Is using [0] to specify binding index clear enough or using `VERTEX_INPUT(0, ...)`
makes more sense? What about future proofing if we one day want to compile this as C++ code.
- This format has nice benefits but it needs manual writting on our ends to modify the shaders.
That said, writting all shaders variations for the workbench prepass was quite easy and fast.
- How would we expose this through pyGPU?

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

Improve formating

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'