Regression in [0] which exposed a problem with GHOST_kGrabHide on Win32
and to some extent X11.
Prior to [0], walk mode used it's own warping logic (hiding the cursor
& recording the motion between events). Using GHOST's grabbing makes
sense in this case as it's not very convenient for operators to
implement their own cursor warping, however doing so exposed a problem
where the mouse cursor could leave the window.
This would happen because the cursor needed to be within 2px of the
screen edge before warping.
Resolve by warping within a small region in the middle of the window.
Note that warping to the window center on each motion would be ideal
but is more involved as the logic for Win32 & X11 doesn't work properly
when every motion warps, so this needs further investigation to support.
This problem doesn't apply to GHOST/Cocoa which warps every motion event
on the spot and GHOST/Wayland doesn't set the mouse position at all to
implement this functionality.
[0]: 4c4e8cc926
For some pixels with transparent surfaces, no depth value would be written
when sampling chooses a reflection/refraction BSDF instead of transparent
BSDF. Now ensure we always write at some some depth value to the pass.
This is still not ideal as the resulting depth values are noisy same as they
are for depth of field and motion blur, but at least there should be no gaps.
The issue here was that the Barbershop benchmark scene was saved with a
custom OCIO config, which leads to some textures having a unknown
colorspace when loading with a default installation.
This is automatically fixed by Blender during image loading, but since
Cycles queried the colorspace before actually loading the image, it
didn't get the updated value in the first render.
To fix this, just re-query the colorspace after the image is loaded.
Note that non-packed images still get treated as raw data if the
colorspace is unknown, but this is at least consistent and doesn't
magically change when you press F12 a second time.
Differential Revision: https://developer.blender.org/D16427
* Sort Training Samples first, since it affects both Surface and Volume guiding.
* Remove "Guiding" from Surface and Volume entries (UI only, the property
still has Guiding in the name)
Change reviewed in the render-cycles module channel.
This was previously needed due to poor compatibility between Visual Studio and
NVCC. But it has not been used for a while now as compatibility seems to have
improved.
The issue here was that the Barbershop benchmark scene was saved with a
custom OCIO config, which leads to some textures having a unknown
colorspace when loading with a default installation.
This is automatically fixed by Blender during image loading, but since
Cycles queried the colorspace before actually loading the image, it
didn't get the updated value in the first render.
To fix this, just re-query the colorspace after the image is loaded.
Note that non-packed images still get treated as raw data if the
colorspace is unknown, but this is at least consistent and doesn't
magically change when you press F12 a second time.
Differential Revision: https://developer.blender.org/D16427
Some of these functions should use locks although they didn't show up
as needing locks at runtime (using valgrind's helgrind), as some aren't
called often or aren't used at all. Add locks for correctness & to
prevent errors in the future.
- GHOST_SystemWayland::disposeContext
- GHOST_SystemWayland::getAllDisplayDimensions
- GHOST_SystemWayland::getButtons
- GHOST_SystemWayland::getMainDisplayDimensions
- GHOST_SystemWayland::getNumDisplays
- GHOST_WindowWayland::setWindowCustomCursorShape
libdecor has a workaround where creating the window would loop until
the windows configure callback ran.
Simplify this workaround by setting the initial state on the underlying
xdg_toplevel struct.
Also correct mixup between bool / GHOST_TSuccess types.
Cycles already treats denoising fairly separate in its code, with a
dedicated `Denoiser` base class used to describe denoising
behavior. That class has been fully implemented for OIDN
(`denoiser_oidn.cpp`), but for OptiX was mostly empty
(`denoiser_optix.cpp`) and denoising was instead implemented in
the OptiX device. That meant denoising code was split over various
files and directories, making it a bit awkward to work with. This
patch moves the OptiX denoising implementation into the existing
`OptiXDenoiser` class, so that everything is in one place. There are
no functional changes, code has been mostly moved as-is. To
retain support for potential other denoiser implementations based
on a GPU device in the future, the `DeviceDenoiser` base class was
kept and slightly extended (and its file renamed to
`denoiser_gpu.cpp` to follow similar naming rules as
`path_trace_work_*.cpp`).
Differential Revision: https://developer.blender.org/D16502
Avoid keeping allocated overly large events_pending vector in case of
long delays between processing events.
While in practice this isn't likely to cause problems, it's better to
avoid keeping unnecessarily large allocations.
Also remove invalid comment.
Consume events in a thread to prevent Wayland's event buffer from
overflowing Waylands internal buffer and closing the connection.
From a users perspective this seemed like a crash.
Details:
- This is a workaround for a known bug in Wayland [0].
Threaded event handling has been if-defed so it can be removed when
it's no longer needed.
- GTK & QT use threaded event handling to avoid this problem
(SDL on the other hand doesn't).
- The complexity and number of locks needed to handle events in a
separate thread is a significant down-side, but as far as I can see
this is necessary.
- Re-connecting to the Wayland server is possible but not practical as
the OpenGL context is lost and as far as I can tell it's not possible
to keep it active (see: D16492).
[0]: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
Using a single draw works in my tests and I couldn't reproduce the
issue noted in the comment.
Also apply minor cleanup, assigning a variable before calling methods to
reduce diff-noise in planned changes.
Render time is reduced for overexposed scenes, by taking into account absolute
light intensity for adaptive sampling.
This can negatively affect some scenes where compositing or color management
are used to make the scene much darker or lighter. For best results adjust the
Film > Exposure setting to bring the intensity into a good range, and then do
further compositing and color management on top of that. Note that this setting
is different than color management exposure.
Previously Cycles' adaptive sampling used sqrt(I) to normalize noise level to
conform to a viewer's eye sensitivity. It is great for darker regions of the
image, but also requests too much samples in bright regions, sometimes several
times more than needed. Highlights can tolerate more noise because in most
examples it is still less noticeable then the noise in darker areas in the same
render.
Differential Revision: https://developer.blender.org/D16392
