In forward path tracing, when we pass volume bounding meshes, we
accumulate `volume_bounds_bounce`. We should match this behaviour in NEE
instead of accumulating `transparent_bounce`.
Pull Request: https://projects.blender.org/blender/blender/pulls/137556
The object was not properly tagged for update when syncing object motion
blur transforms. This caused issue with the camera in volume test after
recent scene update refactoring in 86b67a20d6, but potentially also
other ones.
Pull Request: https://projects.blender.org/blender/blender/pulls/137930
According to the OptiX denoising guide lines, renders should be in the
0..10000 range. As a result, clamping was applied to renders
prior to GPU denoising.
However this lead to a issue where denoising of bright images would
behave differently between CPU OIDN and GPU OIDN as this same clamping
was also applied to the GPU OIDN denoiser.
According to Attila Áfra, a developer working on OIDN, this clamping
isn't neccesary for OIDN. So this commit removes the clamping from
OIDN.
Pull Request: https://projects.blender.org/blender/blender/pulls/137879
This commit fixes a issue where Cycles adaptive kernel compilation
would always undefine adaptive kernel features, resulting in various
issues like incorrect renders.
Pull Request: https://projects.blender.org/blender/blender/pulls/137804
When Emission Sampling in None, we loop through
kernel_data.integrator.num_lights to find the light intersection.
If the light shader changes, the number of lights might change, so we
need to tag the light manager for update to recount the lights.
Pull Request: https://projects.blender.org/blender/blender/pulls/137605
Emission estimate from auto conversion is downscaled to avoid building
a light tree that is expensive to evaluate; however, this estimate is
also used as the final emission value in the kernel if the emission is
constant.
Therefore, only downscale the estimate for the EMISSION_SAMPLING_AUTO
case.
Pull Request: https://projects.blender.org/blender/blender/pulls/137606
When grabbing & hiding cursor under Wayland visually restored the
cursor location but didn't generate a motion event to update the
`wmWindow::eventstate`. Further events that used the cursor location
used the hidden location unless the user moved the cursor beforehand.
It is more convenient for math reasons, for Blender to treat a pen tilt
toward the user as a positive angle. This PR just reverses all the
comments about the expected values. And also reverses the values from
WinTab, Windows Ink, and Wayland to match.
Pull Request: https://projects.blender.org/blender/blender/pulls/137636
This PR removes unused Win32 code that we've had for about 13 years,
hidden behind a define that we've never enabled. The intent of this
optional code was to allow showing Blender windows as transparent,
something that looked pretty cool back then. The main method used was
an API call of DwmEnableBlurBehindWindow, but this function has not
done anything since Windows 8 because styles and tastes have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/137620
On the Windows platform we get an initial bright white flash during
startup, before we start drawing on our canvas. This PR changes that
initial color to a mid-grey that is much less noticeable. After this
initial fill is done we then clear the background brush so Windows will
not use it later and slow down resizing by adding extra WM_PAINT
messages and fills.
Pull Request: https://projects.blender.org/blender/blender/pulls/137488
The GLSL code generated by some OCIO configuration was
not MSL ready. Use our preprocessor on them in order
to make them compatible before creating the GPUShader.
Needs ac7e361f3d
Pen tilt values come into Blender through ghost platforms and device
drivers with inconsistent and ambiguous directions. This PR codifies
that we consider tilt-x positive values to be rightward, negative
values as leftward. Similarly tilt-y positive is away from the user,
negative is toward the user. Comments are updated to make this clear.
This fixes Windows Ink (currently always returning left and away). This
also reverses the Wayland tily-y values to match. We might still have
to consider a user preference to swap directions if we find differences
within a platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/137501
This commit adds some extra prints to terminal related to oneAPI driver
information in the situation that the driver version is considered
incompatible with the current version of Cycles.
Pull Request: https://projects.blender.org/blender/blender/pulls/137272
This patch adds initial cursor support for the blade tool, with bitmaps
for 16x16, 24x24, and 32x32 cursors.
Additional Changes:
- Locked strips now show a "stop" icon when hovered over.
- Previously, the frame to split was truncated when clicking in between frames.
Now, round to the closest frame.
- Previously, the blade operator was able to select padded strip handles
outside of strip bounds. This bug has been resolved, so that selection with
the blade tool can only happen via box-select passthrough.
Pull Request: https://projects.blender.org/blender/blender/pulls/136749
This will be needed to determine if there are volumes in the scene, before
allocation passes to aid volume sampling.
The kernels are now also loaded in the middle of scene update, at a place
where kernel features are known but before the kernels are needed for
displacement and background light evaluation..
Updating the camera to final resolution for progressive refinement still
happens later.
Pull Request: https://projects.blender.org/blender/blender/pulls/137228
The crash was caused by an overflow in the opgl_path_segment_storage
array. It happened because shadow catcher paths would write to the
segments but not clear them. This made it so the next render loop
iteration for the main path starts with non-empty segments in the
guiding data.
Disable training when megakernel is called for the shadow catcher
state.
To ensure this issue is not forgotten when the guiding is ported to
GPU add asserts in the `guiding.h`. While it is a no-op for default
GPU kernels sometimes we do compile debug kernels. But also it acts
as a plain-text reminder to the future-us in working on the code.
There is now also an assert before the main path megakernel to help
catching such cases in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/137291
Remove logic to access LIBDECOR's underlying XDG window since it
required an "dummy-buffer" workaround which caused a crash with recent
drivers that require a DMA buffer.
This introduces a slight flicker on startup in some cases
see code-comments for details.
Ref: !136289
Some OpenXR platforms do not support OpenGL or Vulkan. To support these
platforms we use a bridge. Blender still renders in OpenGL/Vulkan, but
will copy the render result into a D3D11 swapchain.
OpenGL doesn this by importing the D3D11 swapchain into the OpenGL
context and perfor OpenGL calls to update the swapchain. However for
vulkan that could lead to construct 3 context for OpenXR
- Blender GPU Context
- OpenXR D3D Context
- New context that imports the Blender render result and the OpenXR
Swapchain image and copies them.
Due to Direct3D limitations importing into a vulkan context has known
issues (driver + extensions). Secondly we are not sure if we are running
on the same device as the OpenXR swapchain. The solution provided with
this PR is to only support CPU data transfers.
**SteamVR using d3d bridge**
SteamVR normally would use the Vulkan binding. But by changing the binding
priority in code you can make it select the D3D bridge.
<img width="1518" alt="Screenshot 2025-04-10 114534.png" src="attachments/f856bb2b-9ad5-4bb2-9cfd-a1412da9edd1">
It has been tested and validated to work using Mixed reality portal as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/137264
Current Windows on ARM GPUs don't support
extenral memory. External memory is required
for OpenXR. So most likely OpenXR will not work
on these devices.
Most (read all) OpenXR platforms that support
vulkan also require external memory. So might
just be that those platforms won't work at all
on these devices.
In any case when not supported, the GHOST
OpenXR platform will use CPU for data transfer.
The goal is to reduce the affect of the fmod() used in the noise code,
which was initially reported in the comment:
https://projects.blender.org/blender/blender/pulls/119884#issuecomment-1258902
Basic idea is to benefit from SIMD vectorization on CPU.
Tested on Linux i9-11900K and macOS on M2 Ultra, in both cases performance
after this change is very close to what it could be with the fmod() commented
out (the call itself, `p = p + precision_correction`).
On macOS the penalty of fmod() was about 10%, on Linux it was closer to 30%
when built with GCC-13. With Linux builds from the buildbot it is more like 18%.
The optimization is only done for 3d and 4d noise. It might be possible to
gain some performance improvement for 1d and 2d cases, but the approach would
need to be different: we'd need to optimize scalar version fmodf(). Maybe
tricks with integer cast will be faster (since we are a bit optimistic in the
kernel and do not guarantee exact behavior in extreme cases such as NaN inputs).
Pull Request: https://projects.blender.org/blender/blender/pulls/137109
This PR add support to use a win32 handle to perform share render
result with the OpenXR vulkan instance. This is only possible when
the GPU matches. Otherwise a CPU roundtrip will be performed.
Pull Request: https://projects.blender.org/blender/blender/pulls/137093
Commit be63ebd961
This is causing issues with CUDA kernel compilation in some setups, even
though the builbot is ok. Since this isn't yet working for oneAPI anyway,
revert all the changes to Cycles kernel compilation for now.
Includes win32 specific extensions definitions when including
`vk_common.hh`. Inside `gpu_context.cc` vulkan needs to be
included before opengl, otherwise windows 10 builders will
report a warning.
```
[6421/7520] Building CXX object source\blender\gpu\CMakeFiles\bf_gpu.dir\intern\gpu_context.cc.obj
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\minwindef.h(130): warning C4005: 'APIENTRY': macro redefinition
C:\Users\blender\git\blender-vexp\blender.git\lib\windows_x64\epoxy\include\epoxy/gl.h(59): note: see previous definition of 'APIENTRY'
```
Pull Request: https://projects.blender.org/blender/blender/pulls/137134
