-
Notifications
You must be signed in to change notification settings - Fork 969
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: OpenXR integration #1387
WIP: OpenXR integration #1387
Conversation
"openxr", | ||
"hal/use-openxr", | ||
"wgt/use-openxr", | ||
"gfx-backend-vulkan/use-openxr", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current PR supports only Vulkan-based OpenXR (are others possible?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they are, at least dx and gl are supported by OpenXR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from what I've seen from the docs its GL and VK
wgpu-types/Cargo.toml
Outdated
|
||
[dependencies] | ||
bitflags = "1.0" | ||
serde = { version = "1.0", features = ["serde_derive"], optional = true } | ||
openxr = { version = "0.14", features = ["loaded"], default-features = false, optional = true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eventually, is it okay to have openxr as an optional dependency?
} | ||
|
||
/// FIXME FIXME FIXME is this okay? | ||
pub struct OpenXRHandles { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These OpenXR concepts are required at engine-space (bevy) in order to communicate with openxr. This is one take at transferring them between
@@ -17,6 +17,10 @@ | |||
use serde::{Deserialize, Serialize}; | |||
use std::{num::NonZeroU32, ops::Range}; | |||
|
|||
#[cfg(feature = "use-openxr")] | |||
/// OpenXR | |||
pub mod openxr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naming clash with openxr crate, other names?
self.device_create_texture_raw_image::<B>(device_id, desc, None, id_in) | ||
} | ||
|
||
pub fn device_create_texture_raw_image<B: GfxBackend>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic here is modeled from https://github.com/Ralith/openxrs/blob/5283daa09ddbe7170069ff3ea9e42e8a8a9ff4bc/openxr/examples/vulkan.rs#L537 - basically a raw image is required for the swapchain
I'll close this - there's a better encapsulation approach with raw handles that's being continued at #1609 |
Connections
One take at resolving OpenXR support (#602). See https://github.com/blaind/xrbevy
The code in this pull request is not even close to merge-able, but I thought its good idea to open it for further discussion.
See also gfx-rs/gfx#3761 and gfx-rs/wgpu-rs#910
Description
For architecture of the pull request, see https://github.com/blaind/xrbevy/blob/main/docs/architecture.md (evolving document)
Testing
(TODO)