| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Addresses T76082.
Since the DirectX backend does not work for AMD gpus
(wglDXRegisterObjectNV() fails to register the shared OpenGL-DirectX
render buffer, displaying a pink screen to the user), the original
solution was to use SteamVR's OpenGL backend, which, as tested
recently, seems to work without any issues on AMD hardware.
However, the SteamVR OpenGL backend (on Windows) was disabled in
fe492d922d6d since it resulted in crashes with NVIDIA gpus (and still
crashes, as tested recently), so SteamVR would always use the
AMD-incompatible DirectX backend (on Windows).
This patch restores use of the SteamVR OpenGL backend for non-NVIDIA
(AMD, etc.) gpus while maintaining the DirectX workaround for NVIDIA
gpus. In this way, issues are still resolved on the NVIDIA side but
AMD users can once again use the SteamVR runtime, which may be their
only viable option of using Blender in VR.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D12409
|
|
07c6af413617 was missing include.
|
|
This adds support for two Varjo specific OpenXR vendor extensions:
1) XR_VARJO_QUAD_VIEWS
2) XR_VARJO_FOVEATED_RENDERING
Together these enable human eye resolution rendering on supported
devices (currently mainly Varjo XR-3 and VR-3).
In addition, there's a detection for Varjo OpenXR runtime.
This has been tested on real Varjo XR-3 hardware and Varjo Simulator
and confirmed to function correctly. Foveation works, and the views are
rendered correctly for all the four views.
Reviewed By: Peter Kim, Julian Eisel
Differential Revision: https://developer.blender.org/D12229
|
|
|
|
Enables all currently documented OpenXR controller profile
extensions (Reverb G2, Vive Cosmos, Huawei Controller) in order to
support bindings for more VR hardware.
This is necessary because, if these extensions are not enabled, the
OpenXR runtime will return an error when creating a binding with one
of these profiles.
Does not bring about any changes for users at the moment, since
default controller actions have not yet been exposed to users (will
be addressed with D10944, D10948, and D11271).
|
|
Originally mentioned that absolute tracking was disabled, which is
wrong because absolute tracking (skipping application of eye offsets)
is always available, although it may not give the expected result of
persistent tracking origins across sessions if the stage space is
unavailable (hence the need for a warning).
Now, the warning makes no mention of absolute tracking, instead
informing the user that the local space fallback will be used and
that they should define tracking bounds via the XR runtime if they
wish to use the stage space.
|
|
Also hyphenate 'mouse-move' use doxy sections in render_update.c &
move function comment from the header to the source.
|
|
Assignment missed.
|
|
|
|
This addresses reduced visibility of scenes (as displayed in the VR
headset) that can result from the 8-bit color depth format currently
used for XR swapchain images.
By switching to a swapchain format with higher color depth (RGB10_A2,
RGBA16, RGBA16F) for supported runtimes, visibility in VR should be
noticeably improved.
However, current limitations are lack of support for these higher
color depth formats by some XR runtimes, especially for OpenGL.
Also important to note that GPU_offscreen_create() now explicitly
takes in the texture format (eGPUTextureFormat) instead of a
"high_bitdepth" boolean.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D9842
|
|
During the processing of a continuous drag event, other mouse move
events may be in the queue waiting to be processed.
But when a mouse wrapping happens, these waiting mouse move events
become out of date as they report a mouse position prior to wrapping.
The current code ignores these events by comparing their `timestamp` to
the time recorded in the last mouse wrapping.
The bug happens because the computed value in
`mach_absolute_time() * 1e-9` for some reason is incompatible with the
value of `[event timestamp]`.
Since macOS 10.6, we have a new way to get the amount of time the
system has been awake. `[[NSProcessInfo processInfo] systemUptime]`.
Using this updated method fixed the problem.
Differential Revision: https://developer.blender.org/D12202
|
|
This is a slight refactoring of the Win32 IME code to remove the use of
Language IDs, which is now strongly deprecated. Instead this uses the
new recommended Locale Names, ie ISO-639-1 2-letter abbreviated names
like "en" for English rather than ID 0x09.
See D12143 for more details.
Differential Revision: https://developer.blender.org/D12143
Reviewed by Ray Molenkamp
|
|
No functional changes.
|
|
|
|
Addresses the remaining portions of T77137 (Python API for Controller
Interaction), which was partially completed by D10942.
Adds an XR "action maps" system for loading XR action data from a
Python script. Action maps are accessible via the Python API, and are used
to pass default actions to the VR session during the
xr_session_start_pre() callback.
Since action maps are stored only as runtime data, they will be
cleaned up with the rest of the VR runtime data on file read or exit.
Reviewed By: Julian Eisel, Hans Goudey
Differential Revision: https://developer.blender.org/D10943
|
|
Provides several important improvements to the runtime action
bindings operation and internal API.
Moves input-specific action data (input thresholds, input regions,
pose offsets/spaces) from actions to more granular action bindings.
This allows a single action to be mapped to a variety of inputs,
without having to share a single input threshold, region, or space.
Also removes the need for action space creation API, as spaces for
pose actions will be automatically created with the bindings.
The correct action data for the current inputs is set by calling
xrGetCurrentInteractionProfile() to get the current profile and then
retrieving the corresponding mapped data.
Does not bring about any changes for users since only internal
runtime functionality is currently affected.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D12077
|
|
GHOST_ImeWin32::SetInputLanguage() has a confusing name because it does
not set the input language. It actually retrieves the current input
locale from the OS and caches the value of the current input language
ID. Therefore this patch renames it to "UpdateInputLanguage"
Differential Revision: https://developer.blender.org/D12134
Reviewed by Ray Molenkamp
|
|
This removes one member of GHOST_ImeWin32 that is not used and cannot
be used in the future. It is holding the result of ImmIsIME, which is
whether an input language supports IME. It does not indicate that one
is in use, turned on, composing, in English mode, etc.
see D12131 for more information.
Differential Revision: https://developer.blender.org/D12131
Reviewed by Ray Molenkamp
|
|
|
|
|
|
|
|
When entering characters using IME on Windows, Japanese and Chinese
will both usually result in the first keystroke being duplicated. The
problem is that we are informed too late, after the first key is
pressed, that we are IME composing. This patch ensures we are entering
non-English characters using ImmGetConversionStatus() and then deals
with editing keys (like arrows and backspace) on a per-language basis.
see D11929 for more details.
Differential Revision: https://developer.blender.org/D11929
Reviewed by Brecht Van Lommel
|
|
After the switch to enable EGL over GLX. No need to print this debugging
information always.
|
|
Running multiple times would re-indent differently.
|
|
|
|
|
|
This reverts commit c971c851d38ad52779fa5d75c86bbfb83abf660b.
This change was part of the still-under-review patch D11489, which
hasn't been accepted yet.
|
|
|
|
|
|
|
|
|
|
Addresses T76003. When using VR with Eevee and viewport denoising,
scene geometry could sometimes be occluded for one eye. Solution is
to use a separate GPUViewport/GPUOffscreen for each VR view instead
of reusing a single one for rendering.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D11858
|
|
|
|
Improves control over the XR reference space by using the stage ref
space (user-defined tracking bounds) instead of local ref space
(position at application launch), if available. Also adds an
"absolute tracking" session option to skip applying eye offsets that
are normally added for placing users exactly at landmarks.
By enabling absolute tracking, users can define the tracking origin
in a way that is not linked to the headset position. Instead, the
tracking values given by the XR runtime are left unadjusted and a
user can manually calibrate an "origin" landmark object to adjust to
their real world space.
Can be useful for applications that use external tracking systems
and those that primarily only need to use controllers and not the
headset (e.g. motion capture).
The absolute tracking option requires an update to the VR
Scene Inspection addon to be accessible by regular users.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D10946
|
|
The same comments were written in clientToScreen and screenToClient in
GHOST. I corrected them.
Ref D11986
|
|
|
|
Use C comments for plain text.
|
|
|
|
|
|
This was accidentally committed by rBecbf838feefc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
