Thanks to the webXR standard, it is now feasible to deliver virtual reality experiences on the world wide web. All modern VR headsets have browsers that implement webXR.
Authoring apps like krpano and Pano2VR make it easy to build web pages that create immersive virtual tours on webXR capable headsets. Both packages provide simple one-click local webservers that make it easy to test their productions. But viewing these pages locally presents a problem, because webXR requires a secure (https) internet connection. It does support http connections to a server running on the local host. But for VR, the local host is the headset, not your PC.
One possible solution is to install a full scale https-capable web server on the PC, another is to install a local web server on the headset. Though feasible, both are serious technical challenges. The second can also be inconvenient, because you have to download web page files to the headset. Luckily there is a third way, that is far simpler to set up and does not require file downloads. It uses a TCP feature called reverse port forwarding to make a web server on the PC appear to be local to the VR headset. Then you can use the krpano or Pano2VR testing server to view tours on the headset.
I’ll describe how to do it on the currently most popular VR headset, the Meta Quest 2, with a host PC running Windows (the procedure for Linux is very similar). Like many smart devices, the Quest 2 runs the Android operating system, so we will use the Android Debug Bridge tool, adb, to set things up. There are a few prerequisites. On Windows, you must install a custom USB driver from Oculus to connect adb to the headset. And you need to run the Quest in developer mode. To enable that you must first register as a Quest developer. Then you can use the Meta Oculus smartphone app to switch developer mode on and off. There are links to downloads and detailed instructions at the end of this post.
The working connection between the PC and the Quest can be a USB cable or a WiFi LAN. In either case the procedure starts with a USB connection. Unfortunately you must repeat this setup each time you restart the headset or PC; fortunately that takes just a few clicks and shell commands. The examples shown here assume that the directory containing adb is on the command shell’s Path list. If not, you may have to use a pathname to adb.exe.
With the Quest running in developer mode, connect it to the PC with a USB cable. It will display a request that you allow file access by the PC. Do that. Then it will display a request that you allow USB debugging. Check “always allow from this computer” then click OK. From now on the Quest will accept debug connections when in developer mode, and you can set up reverse port forwarding as follows.
Start your local web server and and note the port number at the end of its IP address. In this example that is 8090, the default for the krpano testing server.
Connect the Quest to the PC with a USB cable; allow file access. In a command shell, type adb devices You should get a response showing the headset as the only attached device (if there are more, you probably already know how to direct adb commands to a specific device). Next, type adb reverse tcp:8090 tcp:8090. You should now be able to view VR pages on the PC in the Quest browser using the URL http://localhost:8090.
If you prefer an untethered connection, a few more steps are needed. First, you need the headset’s IP address on the LAN. The command adb shell ip route will get it, as the number following “src”. For this example let’s assume it is 10.0.0.208. Next, start an adb communication channel on an unused port, for example 5555: adb tcpip 5555 and connect the headset to it: adb connect 10.0.0.208:5555. That’s it.
For the WiFi connection, you will also need to add a custom rule to the PC’s firewall, that permits the headset to access the web server port. The details will depend on your firewall software; in general the rule will include a protocol name (TCP), direction (in and out), a range of IP addresses (that includes the headset’s LAN address) and local and remote ports (both the server’s port, here 8090). This need only be done once.
With a LAN connection you should be able to move the headset anywhere within the range of the WiFi router. On a 6-dof headset like the Quest 2 the play space safety system will interfere with that, but you should be able to disable it by turning off headset tracking. On the Quest 2 the switch is in settings>system>headset tracking. Leaving it off is fine for the typical virtual tour, which does not exploit head tracking. If you are testing a 6-dof experience, you will need to switch headset tracking back on at the viewing location, and establish a new play space boundary. It is safest to switch tracking off again before moving to a new location. Do not be tempted by the Quest developer mode feature that (partially) disables the Guardian. This does not stop head tracking, and if you move very far from the original play space, the Quest can get into a permanent state where it will no longer accept any play space boundary as valid; the only cure for this is a factory reset.
I learned this method from these web pages:
https://developer.oculus.com/documentation/native/android/ts-adb/
Here is how to get a Quest into developer mode:
https://developer.oculus.com/documentation/native/android/mobile-device-setup/
Here are links to download the needed software:
https://developer.android.com/studio/releases/platform-tools
https://developer.oculus.com/downloads/package/oculus-adb-drivers/