As documented here: https://developer.oculus.com/documentation/native/android/mobile-native-manifest/

Using the syntax of cargo-apk 0.7 https://crates.io/crates/cargo-apk

This fixes a few lifecyle issues. In particular, the app can be launched again through the oculus menu.

It seems that currently the reported FPS numbers are exactly 50% of what the devices are capable. E.g. on oculus quest 2 with 72fps the example runs at 36fps, and with quest 2 set to 90fps, example reports 45 fps.

Also detectable with monado:

 WARN [log_frame_time_diff] Frame late by 16.67ms!
 WARN [log_frame_time_diff] Frame late by 16.67ms!
 WARN [log_frame_time_diff] Frame late by 33.33ms!
 WARN [log_frame_time_diff] Frame late by 16.67ms!
 WARN [log_frame_time_diff] Frame late by 33.33ms!

Possibly every 2nd frame is waited for, but not rendered?

Currently the android (Oculus Quest 2) lifecycle has problems. Especially after the initial startup, if user navigates back to the application. Seems like that Oculus may also initialize apps before actually displaying them to user?

Some pointers for investigation:

• main() at https://github.com/blaind/xrbevy/blob/df535495d100697857cfcbe4a58f135b488082b1/examples/xr_apk_scene.rs#L6 can be called multiple times, each from different thread. See https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XR_OCULUS_android_session_state_enable
• event loop handling happens at https://github.com/blaind/bevy_openxr/blob/e48bd27130cfb3b735edf2d6ce6355bb5c2490f0/crates/bevy_openxr_core/src/lib.rs#L124. The process::exit(0) at line 135 should be eventually removed
• Session states explanied at https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#session-states

For running the example, in case of problems current "quick fix" is to just run make run_xr_apk a few times until Oculus kills all remaining instances and launches a new one.

From OpenXR docs:

The engine simulation should advance based on the display time. Every stage in the engine pipeline should use the exact same display time for one particular application-generated frame. An accurate and consistent display time across all stages and threads in the engine pipeline is important to avoid object motion judder. If the application has multiple pipeline stages, the application should pass its computed display time through its pipeline, as xrWaitFrame must be called only once per frame.

OpenXR runtime reports the possible swapchain texture format (see https://github.com/blaind/bevy_openxr/blob/e48bd27130cfb3b735edf2d6ce6355bb5c2490f0/crates/bevy_openxr_core/src/swapchain.rs#L100).

The same format should be used in bevy render graph in order not to lose precision during conversions.

At least repos\bevy\crates\bevy_pbr\src\render_graph\pbr_pipeline\mod.rs should be configured.

Maybe window creation flow can be used? Since swapchain is configured late in the process. Alternatively, texture formats could be enumerated immediately after the openxr session has been created.

could look at the window creation flow to figure out how to do this. The normal graphics context is also created after the window is, and this is in a way a similar flow. Alternatively look at the multiple window example, that deals with late creation of windows and the swapchain for that.

I've added the repos from install_dependencies as submodules instead. This means users only have to do git clone --recursive or git submodule update --init instead of running a batch file.

Hi blaind, I'm really interested in your work since I wanted to make ALVR switch its graphics code and VR runtime to bevy and OpenXR. I saw your PRs and I wanted to give you some suggestions and and also a hand with the implementations. About gfx-hal, I think the OpenXR integration should be made into another crate. Currently there is no way of accessing gfx-hal internals, so I wanted to contribute an API to get backend-specific handles (like VkInstance and VkDevice) and to create gfx-hal objects from these handles. About wgpu, a similar API could be propagated, but I don't know if this is the right call, since the point of wgpu is to have a safe API. The best thing would be for bevy to switch from wgpu to gfx-hal directly, but this easier said than done.