WebXR - A need for standardization

Most XR applications are developed in a game engine like Unreal Engine, Unity or Godot. This comes with a lot of benefits, a lot of functionality needed for XR is readily available for a wide range of devices, be it for VR, AR or MR devices. This makes it relatively easy to develop a simple XR application, compile it into a binary or a package ready to run on the XR device of your choice. The latter is where WebXR applications have major advantage, you host it once on a server and it can be accessed by anyone who has access to the internet and any WebXR capable device.

WebXR - What do you need to know?

Simply put, WebXR is an API (Application Programming Interface) implementation in the browser that gives standardized access to most of the inputs (controller, hand and head movement and orientation, depth sensors, etc) and outputs (the displays) of a XR devices. With this standardized access you could potentially make one application and use it on many different types of XR devices, given that the device has a browser with WebXR support.

It started out in 2014 when it came apparent that more and more hardware suppliers were releasing their own VR devices and all of them with different means of accessing the IO (in- and outputs) of their devices. This created a desperate need for standardization which fueled the idea at Mozilla to develop the specification called WebVR and its corresponding API implementation. This eventually got deprecated in 2018 and evolved into the WebXR API with the rise of more AR and MR devices. Currently it is supported on most commonly used browsers (Firefox you'll need to set a flag).

Usually when you develop a WebXR application you do not directly program it with WebXR API but its used through a library, framework or game-engine that handles most of the usage of the browsers WebXR implementation. The good part is, that most well known current day pieces of software that are used to display 3D content have WebXR support.

Frameworks - Where do we begin?

There is a vast array of libraries, frameworks and web-engines that make use of the WebXR API. This big pool of possibilities can be rather overwhelming when you start out, on top of having to get your way around web development. Out of the list of possibilities I would like to highlight a few of them that are commonly used and have WebXR natively implemented and easily accessible. These are Three.js or A-frame and BabylonJS or PlayCanvas. Where Three.js lays the basis and gives you all the tools and add-ons to visualize your 3D-content with the main focus being a web-based rendering engine. A-frame adds on top of Three.js as a simplification layer that lets you write your VR applications in HTML directly with minimal JavaScript or TypeScript programming needs. Babylon.js and PlayCanvas however can be seen more as a game-engine in the web-browser, they include also other tools like physics engines to develop a full game for in the browser.

Three.js and A-frame - Light weight rendering engines

For most people that are familiar with web-based 3D content Three.js is a well known library which is commonly used to either visualize 3D-scenes or 3D visualizations. It gives a very flexible and light weight modular abstraction layer on top of WebGL and WebXR where you can implement only the parts of the library that you really need. This flexibility however does come at a cost that the code to create a 3D application can sometimes become a bit verbose. Although, this is mainly the applications functionality itself, to have a basic WebXR implementation in your 3D web application with Three.js is rather simple: add a VR-enable button, set WebXR to 'true' and change the default render loop and you are done.

When you are familiar with Three.js you will probably default back to it often but for people that are not so familiar it is recommended to use A-frame which drastically reduces the amount of code needed to implement the same result (albeit less flexible) and has WebXR enabled by default. For example the below simple scene example with A-frame (which can be saved in a file with an HTML extension and opened in your browser) needs 6 less lines then a Three.js implementation to reach equivalent results:

<!DOCTYPE html>
<html>
  <head>
    <script src="https://aframe.io/releases/1.4.2/aframe.min.js"></script>
  </head>
  <body>
    <a-scene>
      <a-box position="-1 0.5 -3" rotation="0 45 0" color="#4CC3D9"></a-box>
      <a-sphere position="0 1.25 -5" radius="1.25" color="#EF2D5E"></a-sphere>
      <a-cylinder position="1 0.75 -3" radius="0.5" height="1.5" color="#FFC65D"></a-cylinder>
      <a-plane position="0 0 -4" rotation="-90 0 0" width="4" height="4" color="#7BC8A4"></a-plane>
      <a-sky color="#ECECEC"></a-sky>
    </a-scene>
  </body>
</html>

Off course, you could directly implement everything in HTML, JavaScript or TypeScript, but both Three.js and A-frame both come with their own interactive simple no-code editors. Three.js hosts their own simple 3D-editor where you can create your own scene and import your own 3D-content and eventually "publish" it, which is nothing more than downloading the needed files in a zip file that can be directly be hosted in whatever way you prefer (for simple hosting see last section of this blog post). For A-frame however its called an inspector and it is more part of the development of the application where you can tweak your 3D scene and change properties of the objects in your scene. For this you first need to setup a A-frame project yourself, but they do provide an example of what it would look like.

Babylon.js and PlayCanvas - Web-based game engines

If you prefer a bit more feature rich development tools, at the expense of bulkier size and longer loading times, then maybe Babylon.js and PlayCanvas could be something for you. Babylon.js has a great online editor, called the playground to script together your scene with an inspector which enables you to debug your scene. This playground also has the nice feature that the whole scene can be downloaded as static HTML files that you can host yourself.

PlayCanvas looks to have the most extensive web-based editor with most basic features that you would expect in a game engine such as: a scene hierarchy view, asset manager, a panel change properties of these assets, etc. The caveat though is that while the PlayCanvas engine is open-source, the PlayCanvas editor is not and has a pricing model, but as you see they do have a free plan which can get you started. PlayCanvas also has means to host your projects directly on PlayCanvas, this gives you a PlayCanvas URL which you can use to distribute your project. To download the scene and host it yourself you do need one of the paid pricing plans.

Hosting - Getting it out there

One common frustration with web-applications in general, and the ones that utilize the WebXR API, is that they do need to be hosted somewhere. This requires the need for hardware or a cloud solution that needs to be available 24/7 for other people to access it through their WebXR enabled browser. This opens up a whole different field of expertise which is beyond the scope of this blog-post. There are however some solutions that require minimal configuration. One of them is the one I often use for testing on my own home network, which is with a 'npm' package called http-server (you can off course use other simple static HTTP servers).

To use this tool, simply save the A-frame example mentioned above in an HTML file called: 'index.html'. Since WebXR does require a secure connection you need to serve it through HTTPS, this requires you to have SSL certificates. The fastest and simplest solutions would be to use your own self-signed certificate created with OpenSSL, or you could obtain the certificates for your organization. Once obtained, you can use the http-server tool in the directory with the command: http-server -S -C <CERTIFICATE-FILE> -K <KEY-FILE>. This will give you a URL with your local IP address under the section "Available on:" in the output. Use this URL in the browser of your XR device (for example the Oculus browser on the Quest 2). If you can't access it from the XR device it could be that the hosting devices Firewall blocks the 8080 port and you might need to open that up. Also note, that if you use the self-signed certificates you will get a warning that the certificate might be unsafe, you can click on "Advanced" and then "Proceed to..." to go to the application.

Keep in mind, this rather brief and crude solution of hosting is not the correct and secure way to have your application open to the world. It serves merely as a way to test out the WebXR application. Besides that, this could be a bit too technical for some and for those, I would advice you to consult an expert within your organization that could host your WebXR application properly.

Auteur

Reacties

Dit artikel heeft 0 reacties