I have a proprietary application that is an unholy fusion of C/gstreamer, Rust/gstreamer, java, and Rust/OpenXR. It is able to track the right-hand controller and paint an object at that position in VR.
I am trying to cut out the java and create an android_main Rust app that is compatible with cargo apk run (although it will still need some gstreamer later on).
I currently have an application ( log the pose of the right hand controller, doesn't seem to work · mutantbob/android-openxr-exp@a2c2de6 · GitHub ) which runs on a Quest 2 and paints a monkey head (suzanne from blender) and the classic color-corner triangle in VR at fixed locations in space.
I brought over my code for tracking the controller position from the working application and logged the result. All I get is zeros:
2023-06-30 10:21:28.935 1817-1848/rust.glutin_openxr1 D/glutin_openxr1::drawc..: space location Ok(Posef { orientation: Quaternionf { x: 0.0, y: 0.0, z: 0.0, w: 0.0 }, position: Vector3f { x: 0.0, y: 0.0, z: 0.0 } })
Unfortunately, the OpenXR library is a binary blob from Meta ( https://developer.oculus.com/downloads/package/oculus-openxr-mobile-sdk/ ) so I can't even go insane digging through the action handler code to figure out why it is giving me zeros in one app, and good data in another.
My current hypothesis is that there is something magical about the java bits in the working application that enables the openxr library to work, but confirming that hypothesis is going to be a fairly long slog of crafting new applications that mix attributes of the working app with the broken app to figure out which element is the problem.
Does anyone here have any insights that can help me fix my android_main app to properly sample the OpenXR controller position?