| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Caused by 6ec83afb1db8.
Technically, a regression since 3.0.
Differential Revision: https://developer.blender.org/D14239
|
|
|
|
This is a workaround until there is a fix in the HIP compiler or driver.
Differential Revision: https://developer.blender.org/D14232
|
|
|
|
|
|
Mousemove events are sent to windows.
In Windows OS, almost all mousemove events are sent to the window whose
mouse cursor is over.
On MacOS, the window with mousemove events is always the active window.
It doesn't matter if the mouse cursor is inside or outside the window.
So, in order for non-active windows to also have events,
`WM_window_find_under_cursor` is called to find those windows and send
the same events.
The problem is that to find the window, `WM_window_find_under_cursor`
only has the mouse coordinates available, it doesn't differentiate
which monitor these coordinates came from.
So the mouse on one monitor may incorrectly send events to a window on
another monitor.
The solution used is to use a native API on Mac to detect the window
under the cursor.
For Windows and Linux nothing has changed.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14197
|
|
|
|
|
|
This patch hides the MetalRT checkbox for AMD GPUs, pending fixes for MetalRT argument encoding on AMD.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14175
|
|
Also move eDupli_ID_Flags doc-string to it's declaration.
|
|
|
|
This fixes T93051, T76405 and maybe others.
Characters like '²', '<' are not recognized in Blender's shortcut keys.
And sometimes simple buttons like {key .} and {key /} on the Windows
keyboard, although the symbol is "known", Blender also doesn't
detect for shortcuts.
For Windows, some of the symbols represented by `VK_OEM_[1-8]` values,
depending on the language, are not mapped by Blender.
On Mac there is a fallback reading the "actual character value of the
'remappable' keys". But sometimes the character is not mapped either.
On Windows, the solution now mimics the Mac and tries to read the button's
character as a fallback.
For unmapped characters ('²', '<', '\''), now another value is chosen as a
substitute.
More "substitutes" may be added over time.
Differential Revision: https://developer.blender.org/D14149
|
|
|
|
|
|
|
|
|
|
Without ray offsets intersections at neigbhoring triangles are found, as
the ray start is exactly at the vertex. There was a small offset towards
the center of the triangle, but not enough.
Now this offset computation is moved into Cycles and modified for better
results. It's still not perfect though like any offset approach, especially
with long thin triangles.
Additionaly, this uses the shadow terminate offset for AO rays now, which
helps remove some pre-existing artifacts.
|
|
|
|
Also add an assert to avoid reproducing the error in the future.
|
|
|
|
This was the last place still using the ray_offset() function.
|
|
|
|
|
|
Also use SRC_ prefix for source variables so cmake_consistency_check.py
detects these files as being known to CMake.
|
|
Helps with building against different OpenXR SDK versions (i.e. for
downstream builds that require specific versions), as the extension was
only defined since OpenXR 1.0.22.
|
|
|
|
|
|
Fixes the following warning:
`'!=': unsafe mix of type 'bool1' and type 'bool' in operation`
|
|
|
|
|
|
|
|
|
|
This commit should suffice to make the shader API agnostic now (given that
all users of it use the GPU API).
This makes the shaders not trigger a false positive error anymore since
the binding slots are now garanteed by the backend and not changed at
after compilation.
This also bundles all uniforms into UBOs. Making them extendable without
limitations of push constants. The generated uniforms from OCIO are not
densely packed in the UBO to avoid complexity. Another approach would be to
use GPU_uniformbuf_create_from_list but this requires converting uniforms
to GPUInputs which is too complex for what it is.
Reviewed by: brecht, jbakker
Differential Revision: https://developer.blender.org/D14123
|
|
# Conflicts:
# intern/opencolorio/ocio_shader_shared.hh
|
|
This reverts commit 7f7c614ecddbcb66de0bff1657366970dede99be.
|
|
This reverts commit 3cebfadb27eb4056d28211708158f9ad8a7459b7.
|
|
Was the cause by ef0e21f0ae71d9ec4ba3cdf6f6a16c9575459ced
|
|
This commit should suffice to make the shader API agnostic now (given that
all users of it use the GPU API).
This makes the shaders not trigger a false positive error anymore since
the binding slots are now garanteed by the backend and not changed at
after compilation.
This also bundles all uniforms into UBOs. Making them extendable without
limitations of push constants. The generated uniforms from OCIO are not
densely packed in the UBO to avoid complexity. Another approach would be to
use GPU_uniformbuf_create_from_list but this requires converting uniforms
to GPUInputs which is too complex for what it is.
Reviewed by: brecht, jbakker
Differential Revision: https://developer.blender.org/D14123
|
|
|
|
When new display driver is given to the PathTrace ensure that there are
no GPU resources used from it by the work. This solves graphics interop
descriptors leak.
This aqlso fixes Invalid graphics context in cuGraphicsUnregisterResource
error when doing final render on the display GPU.
Fixes T95837: Regression: GPU memory accumulation in Cycles render
Fixes T95733: Cycles Cuda/Optix error message with multi GPU devices. (Invalid graphics context in cuGraphicsUnregisterResource)
Fixes T95651: GPU error (Invalid graphics context in cuGraphicsUnregisterResource)
Fixes T95631: VRAM is not being freed when rendering (Invalid graphics context in cuGraphicsUnregisterResource)
Fixes T89747: Cycles Render - Textures Disappear then Crashes the Render
Maniphest Tasks: T95837, T95733, T95651, T95631, T89747
Differential Revision: https://developer.blender.org/D14146
|
|
|
|
|
|
Allows controller-specific action bindings for the HTC Vive Focus 3
controller. Currently not supported by any OpenXR runtimes (save for
the dedicated Focus 3 runtime in developer early-access:
https://forum.vive.com/topic/11354-openxr-support-for-focus-3-early-access-application-form),
but useful to have for the future.
|
|
|
|
|
|
|
|
This affected loading of EXR files with set to Linear ACES colorspace, as
well as the sky texture for in some custom OpenColorIO configurations.
Use the builtin OpenColorIO transform from ACES AP0 to XYZ D65 to fix this.
|
