jme3-vr to be deprecated

[richardTingle]

As discussed in the thread for JME V3.7 jme3-vr is now outdated using OpenVR. OpenXR JMonkeyEngine is supported by user libraries (e.g. Tamarin) and even if a new OpenXR based virtual reality JME core module was to be created it would not be based on jme3-vr (which made compromises to work with the at-the-time many VR standards).

Deliverables:

• Main jme3-vr classes to be marked as deprecated with instructions to use user libraries for OpenXR
• Wiki to be updated noting the deprecation
• Find tickets that are now redundant and propose they be closed

(This is just a header issue, I intend to put in the PR and Wiki changes)

[richardTingle]

PR for deprecation of module: #2175
PR for update to Wiki: jMonkeyEngine/wiki#176

Other issues that this makes redundant:

#1941
#1164

[jseinturier]

Hello,

I'm currently working on the update of jme3-vr to handle OpenXR while keeping existing high level VR interfaces and backwards compatibility with OpenVR implementation.

Even if it's planned to switch to OpenXR, many systems are using OpenVR and at this time, for me, it is quite interesting to keep this functionality.

I've made a tour on user implementations for VR using JMonkey and at this time, most of them do not work with many devices / systems.

I can propose to make the jme3-vr package to evolve has follows:

• Removing old Native OpenVR / OSVR implementations from jme3-vr and keeping only LWJGL_OpenVR based implementation
• Integrating LWJGL_OpenXR implementation (available from LWJGL 3.2)

As only the implementation will change, JMonkey VR classes will not be affected and so, old programs will continue to work.

Have a nice day.

[richardTingle]

@jseinturier Not sure if it changes things but just to let you know I created an OpenXR implementation for JMonkeyEngine called Tamarin

Integrating LWJGL_OpenXR implementation (available from LWJGL 3.2)

I did originally think about this but the APIs between [pre action based OpenVR] to [action based OpenVR and openXR] is really big, an API that abstracted those differences away seemed too painful, which is why I decided to create an entirely new API in Tamarin and propose that jme3-vr be deprecated.

Managing this as a user library is quite a lot easier, I have been able to have a fast release when issues are discovered rather than waiting for a (perhaps annual) JME release. You may want that even if your aim is to create a competitor to Tamarin.

Starcommander was also working on an jme3-xr at #2012

keeping existing high level VR interfaces and backwards compatibility with OpenVR implementation.

As only the implementation will change, JMonkey VR classes will not be affected and so, old programs will continue to work.

I'm not sure how that would be possible as OpenXR requires an action manifest to be programmatically submitted whereas OpenVR required an XML one and pre OpenVR didn't have an action manifest concept and had constants for particular controller buttons