branchpanic / raylib-openvr Goto Github PK

It would be more useful if the positions given for tracked devices were absolute instead of relative. The latter pushes too much work onto the user for a common use case.

It seems the best way to handle OpenVR input is using predefined actions. We will need a way to load action manifest files and read various input types. It looks like OpenVR does this without too much pain, so this might only be a matter of wrapping the corresponding IVRInput functions.

Open VR runtime software like Oculus Dash and compare its hand/controller positioning to the cubes in the hello_vr demo. The cubes are noticeably offset.

In the proof-of-concept demo, the player is anchored at <0, 0, 0>.

Almost every VR experience needs access to tracked device data, like the HMD and controller positions. It would be best if we not only expose OpenVR's transformation matrix but also individual vectors for position and orientation.

Right now, every GL call to draw the scene is made 3 times (left eye, right eye, simulated camera). Compare this to raylib's stereo rendering implementation that batches all the actual draw calls and only changes the view/projection matrices for each viewpoint. This will benefit both the user (better performance) and developer (only need one begin/end call in the style of InitVrSimulator/CloseVrSimulator).

It may not be possible to do this without modifying raylib unless RenderBatch and friends are made public. I'm willing to explore making some upstream contributions, though, so that might not be too much of a problem.

The ultimate goal is to render both views in less than 2x the calls to render one view.

QuaternionFromMatrix(mat) occasionally results in division by 0.

I wanted to make this issue as a note that I'm not against exploring OpenXR over OpenVR for this project, since OpenXR seems like the future. I tried to get raylib and OpenXR working in the same project, but unfortunately ran into problem after problem including Windows.h (and pre-existing #define tricks didn't seem to work). Maybe I'll explore it again when I have more time.

What this means today is that the API has to be flexible enough to support either backend. On the developer end, this will look like a #define before importing raylib.

For now, I'm going to focus on developing good, working OpenVR support first. After achieving that basis, it should be easier to design the API.

Update: Totally forgot about WebXR as well. That would be fun to support. See https://www.w3.org/TR/webxr/, https://github.com/VhiteRabbit/emscripten-webxr.

OpenVR helpfully provides meshes for tracked devices. It would be useful to expose these as Raylib models.

A lightweight framework like raylib could be very useful for creating VR overlay applications.

Raylib recently updated its VR simulator code, allowing for further configuration. This may or may not be useful to us.