Use XCURSOR_THEME & XCURSOR_SIZE environment variables for Wayland.
While this isn't an official part of the spec, many Wayland compositors
& applications use these variables.
* Group bounding box, bounding cone and energy to a struct called `LightTreePrimitivesMeasure`
* Add utility functions to add primitives to nodes or buckets
* Precompute the split bucket cost to improve efficiency (about 1.4x expected)
Pull Request: https://projects.blender.org/blender/blender/pulls/105931
Push a task to `TaskPool` when more than `MIN_PRIMS_PER_THREAD` primitives are to be processed. The nodes are rearranged in a depth-first order when copied to the device.
Tested with the scene in #105550 on an Apple M1 Ultra (20 cores), about 11x speedup.
Pull Request: https://projects.blender.org/blender/blender/pulls/105862
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
The name #ensure_valid_reflection seems to indicate that the resulted
reflection must be valid, whereas in the reality it only ensure validity
for specular reflections. The new name matches the behavior better.
This function checks if the shading normal would result in an invalid reflection into the lower hemisphere; if it is the case, the function raises the shading normal just enough so that the specular reflection lies above the surface. This is a trick to prevent dark regions at grazing angles caused by normal/bump maps. However, the specular direction is not a good representation for a diffuse material, applying this function sometimes brightens the result too much and causes unexpected results. This patch applies the function to only glossy materials instead.
Pull Request: #105776
Actually both potential roots lie in the interval [0, 1], so the
function ended up checking both roots all the time.
The new implementation explains why only one of the roots is valid; it
saves two square roots and a bunch of other computations.
This changes the maximum viewport resolution divider for Cycles to
help users get a more responsive viewport.
This is done by changing the maximum viewport resolution divider
to a divider that aims to have the largest axis of the viewport
roughly equal to 128 pixels.
Depending on the circumstances, this change can result in a few
noticeable differences:
- Users with slow hardware and a large pixel_size, or slow hardware
and a low resolution screen, may observe a higher resolution viewport
during navigation, making the scene more readable. However this comes
at the cost of reduced responsiveness.
- Users with slow hardware and a low pixel_size and high
resolution screen may observe a lower resolution viewport during
navigation, providing a more responsive viewport during navigation.
Along with that, how Cycles iterates through resolution dividers
is changed to promote quick transitions between resolution dividers.
Meaning users don't need to wait through as many iterations to get
from a low navigation resolution to a 1:1 viewport resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/105581
When linking a texture directly to the material output, it's likely being
done for the purpose of previewing. In that case, bias the heuristic towards
not building a light tree, as it's likely not needed and slow on dense meshes.
Workaround for a crash when `addComputePipelineFunctionsWithDescriptor` is called *after* `newComputePipelineStateWithDescriptor` with linked functions (i.e. with MetalRT enabled). Ideally we would like to call `newComputePipelineStateWithDescriptor` (async) first so we can bail out if needed, but we can stop the crash by flipping the order when there are linked functions. However when addComputePipelineFunctionsWithDescriptor is called first it will block while it builds the pipeline, offering no way of bailing out.
Note that this only has an impact when the "MetalRT (Experimental)" option is checked.
Pull Request: https://projects.blender.org/blender/blender/pulls/105629
Archlinux faced an issue with AoT compilation: https://bugs.archlinux.org/task/77554
These were due to compiler flag strings handling going wrong when cmake
calls the custom command. It ended up moving quotes around, leading flags to
get passed to the main compiler instead of the graphics compiler and trigger
the following error: "Unrecognized build options: -ze-opt-regular-grf-kernel".
Pull Request: https://projects.blender.org/blender/blender/pulls/105615
The C4100 warning is related to unused formal parameters in functions.
Enabling it better aligns with "-Wunused-parameter" option in other
compilers.
While suppressing it with `__pragma(warning(suppress:4100))` is not the
same as using `__attribute__((__unused__))` in GCC or Clang, it is
still preferable to use it over completely hiding the warning.
This ensures consistent warning behavior across compilers and improves
code quality by addressing unused function parameters.
(Note that some warnings in Windows-specific code have already been
silenced in 7fcb262dfd)
Pull Request: https://projects.blender.org/blender/blender/pulls/105534
Currently a developer that starts blender with `--debug-gpu` or
runs the GPU test cases can receive an error when not the full
VulkanSDK is installed.
The VulkanSDK isn't required for normal developement and
therefore it is better to show it as a warning.
NOTE: VulkanSDK is adviced to use when developing in the Vulkan
backend as it contains tools that helps/speed up the development
and validation during development.
Pull Request: https://projects.blender.org/blender/blender/pulls/105599
The traversable handle of a BLAS may be zero when the relevant geometry
is empty (no triangles/curves/points/...), as no BLAS is built in such cases.
It is not correct to attach a zero handle to a TLAS, so filter out such instances.
