We are building an agnostic solution that allows you to stream VR content from your own catalog, for this we imaging the following user journey:
1.- The user selects the app that wishes to stream (the service sets up the server under the hood).
2.- The user waits until the server and app are ready to be used, then wears the headset and uses the app.
3.- (Optional) if the app requires any in-screen configuration (i.e. login, setting up the virtual environment, level, etc.) then allow the user to set the app before wearing the headset.
The sample CloudXR client apps require the headsets to be up and running in order to establish a connection, we have tried (using the client for Oculus Quest) to manually call cxrConnect while the headset is in sleep mode but it always returns cxrError_No_Decoder.
Many VR apps require some initial input from the user, so we are trying to avoid making the user wear the headset for starting the connection and launching the app, then taking it off so they can configure the app, and then putting it back to properly use the remote app.
It would be simpler to establish the connection even if the headset is in sleep/standby mode and as soon as the headset awakes then process the streaming but with the connection already open.
Depending on the hmd, that might not be physically possible as when in sleep mode there are some resources, some state, that just don’t allow a local app to start up fully.
We’ve discussed possibly having a preset configuration on the server side for the EXACT device spec that will connect, so that we can in essence pre-seed the initial connection/setup of the virtual HMD. I have no further information on that though, as to feasibility or timeline.
I assume that your issue is trying to launch a VR app on the server, and it runs into issues because there isn’t “an attached HMD” yet?
We know that we have to establish a connection before launching a remote VR app so currently, we do follow this scheme, but we would like to be able to establish the connection without the need of the user to put on the (standalone), this in case there is additional configuration required for the VR app once it is launched.
This would be particularly important for standalone devices (Oculus, Wave, and Pico).
Understood. While we may in the future be able to ‘preconfigure’ the server for one specific device, it’s really difficult to launch an application on a sleeping/off-head HMD, due to them each handling android lifecycle a bit differently. On certain devices, the app process is ‘frozen’ when the device is asleep.
But if the application needs per-run configuration, then either needs to be done from within VR, by a second user (or the first user with the HMD slid up onto forehead… :) ), or pre-configured if the app allows using a commandline or file to do so.
I think a feasible solution would be to start up the server (knowing beforehand the headset that will end up being connected to it) and then just wait for the client to connect when it awakes, this also aligns with the idea of having preset configurations for the server.
Pico and Wave have similar implementations for their streaming solutions, they start a runtime in the server and wait for the headset to connect.
Regarding the best practices for per-run configurations, I agree 100%, unfortunately, the issue is that in enterprise the standards and needs are different than in other industries (like videogames or the consumer market), an example is the intense use of CAD data instead of well-optimized 3D models and lightweight formats, in our case, many apps are designed in a way that an instructor manages the configuration and guidance of a trainee from a PC.
Modifying the Windows sample client to load a fake client in the server with the very same values as the headset to be connected seems to work fine, the fake client initializes SteamVR and can be closed immediately after establishing the connection, then any client from the very same preset (i.e. Oculus, or Pico, or Focus) can be connected.
I believe we’re working on this for an upcoming release, with the ability to use some descriptive file to define the HMD expected (so as to not hard-code anything, and not need a hacked client to start things off – though that’s a good hack!).