stride
stride copied to clipboard
stride3d
Openxr support (master)
PR Details
Adds support for OpenXR using DX11 Same as https://github.com/stride3d/stride/pull/1441 but against master instead of master-4.0
Description
Port of https://github.com/anotherdevguy/stride/tree/openxr to work with DX11 instead of Vulkan. Supports the same functionality as currently supported by OpenVR except for the recenter function which is not supported by OpenXR itself and should be done manually from the engine.
Motivation and Context
OpenXR superseeds OpenVR and supports many more features and devices.
Types of changes
- [ ] Docs change / refactoring / dependency upgrade
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist
- [ ] My change requires a change to the documentation.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
Thanks for your contribution! I gave it a quick try and it doesn't compile for any non-D3D11 platforms (some ifdef makes symbols unavailable):
19>C:\dev\stride\sources\engine\Stride.VirtualReality\OpenXR\OpenXRHmd.cs(358,53,358,72): error CS0103: The name 'session_create_info' does not exist in the current context
19>C:\dev\stride\sources\engine\Stride.VirtualReality\OpenXR\OpenXRHmd.cs(395,35,395,41): error CS0103: The name 'images' does not exist in the current context
19>C:\dev\stride\sources\engine\Stride.VirtualReality\OpenXR\OpenXRHmd.cs(357,13,357,20): warning CS0162: Unreachable code detected
19>C:\dev\stride\sources\engine\Stride.VirtualReality\OpenXR\OpenXRHmd.cs(538,17,538,33): error CS0103: The name 'swapchainPointer' does not exist in the current context
19>C:\dev\stride\sources\engine\Stride.VirtualReality\OpenXR\OpenXRHmd.cs(538,36,538,53): error CS0103: The name 'GetSwapchainImage' does not exist in the current context
19>C:\dev\stride\sources\engine\Stride.VirtualReality\OpenXR\OpenXRHmd.cs(1054,42,1054,56): error CS0103: The name 'render_targets' does not exist in the current context
To try it yourselve, you can edit build\Stride.build.props and add following property:
<StrideGraphicsApiDependentBuildAll>True</StrideGraphicsApiDependentBuildAll>
What about the report from motzi that the performance isn't near the one of OpenVR? Was this addressed or the problem identified?
The other point was my comment above about the serialization of the public property that isn't stored as a variable, but computed. Was this tested with a project (load/save)?
And do older projects with customized VR settings load and save correctly?
"What about the report from motzi that the performance isn't near the one of OpenVR? Was this addressed or the problem identified?" This was not investigated further yet. It will be much easier to investigate further once we have the new backend integrated for end-users to test and report findings.
"The other point was my comment above about the serialization of the public property that isn't stored as a variable, but computed. Was this tested with a project (load/save)?" You're referring to this. Can you please elaborate? How exactly would this be tested? Or even suggest a change/fix?
"And do older projects with customized VR settings load and save correctly?" Where do you see a problem exactly? This is an optional new backend that shouldn't interfere with any existing settings. Or what might we be missing?
About performance, if there's any difference, it must be on the specific OpenXR runtime. The only possible optimization in terms of performance that I can think of is passing the texture from the swapchain that openxr holds directly to the engine to render to instead of getting the last texture from the engine and copying it to the swapchain one. It would avoid only one texture copy which I won't make a significant difference to justify the complexity introduced in the code by such change.
Not sure how the save system works but happy to do some texts if anyone can let me know where I should be looking into and do whatever changes are needed.
About older projects as Joreg said I don't think is should have any significant impact since I can imagine people are, in most cases, choosing a specific API rather than leaving the engine choose one since there are differences between APIs but happy to test that as well. In any case if saving/loading doesn't have an issue I can imagine this shouldn't be a problem either
Ok I think the remaining issues are now fixed. I've removed the code from the CopyMirror property as it wasn't really doing anything since it's something that can only be known at runtime when a specific API is selected.