I built a VR platform for a small, foreign language training services firm. WebXR made it possible for us to target the lowest-friction device available (Meta Quest 2) while also not having to slow our project velocity by having to submit updates for approval in the app store.
People who say JS on the Quest 2 isn't fast enough to do good VR don't know what they are talking about. The problem is that a lot of small, indie developers only know the most naive way to implement things and then blame the platform for their lack of algorithms training.
I had originally started the project in Unity 3D. I eventually rewrote everything in WebXR because--while the naive path in Unity was faster than WebXR--the ideal path in Unity was nearly impossible to implement. I haven't done anything in Unity for about 3 years now, so maybe it has changed, but basic things like decoding textures happen on the render thread, which makes it impossible to use the Unity happy path to implement a dynamic XR app that wasn't prone to making people puke. While I was still tilting at the Unity windmill, I had a large amount of code that was just dedicated to decoding images before using them as textures, tasks Unity should have been able to handle itself, except for the fact that Unity is built by people who have never had to make a game or app themselves before.
There's a reason the loading screens on VR Chat are so long and boring--they can't slipstream live objects in because they haven't done the hard work of throwing away 90% of Unity's bullshit framework code. So they have to hide the dropped frames behind a scene fade-in/fade-out.
With WebXR, you get the full browser ecosystem to work with. Web Workers. Web Audio being off-render-thread by default. Fetch API. IndexedDB. It's somewhat popular to complain about Web APIs because some of them have some weird quirks and most of them don't agree on how to design an API, but you have no idea how much worse it can get. If you think browser app development is bad, trying making an app in Unity sometime.
Wonder what's the story behind this not being made by the Khronos Group. Especially since, at least according to Wikipedia, it's based on Vladimir Vukićević's work.
The name choice is interesting. If one of the first things in your FAQ is "the name probably made you think this is thing X. it's not", then maybe there was a flaw in your naming process.
I'm talking about WebXR, which is for some reason the name of the standard developed by W3C.
"As such it may seem like WebXR and OpenXR have a relationship like WebGL and OpenGL, where the web API is a near 1:1 mapping of the native API. This is not the case with WebXR and OpenXR, as they are distinct APIs being developed by different standards bodies."
Alright, fine. WebVR predates OpenXR by about 3 years. When WebVR was renamed to WebXR, OpenXR existed in name only, and nobody knew if, once the spec even came out, it would get adopted. It wasn't a well-known name at large by that point, and there was significant concern from the W3C to avoid confusion with creating separate WebVR and WebAR APIs. So, "they should have been careful to avoid confusion with OpenXR" gets it backwards, over-assigning the ownership of "XR"-named things to Khronos.
For me the main advantage of WebXR is that one can create complex 3D objects at runtime/on the fly without havjbg to load them as assets or compiling them into the binary.
Any thougts on the best way to do this in classic runtimes like Unity or Unreal (which scripting plugins, which base construction objects/assets?)?
The main issue I have with WebXR, though, is it being canvas-based instead of being page/HTML-based, resulting in graphic-oriented products instead of structure-oriented ones (e.g. 3D web pages) which would allow placing all the dynamic and complex HTML objects that were developed over the last few years. Any good known approach to solve this?
Just a heads up, when folks say “complex 3d objects”, it’s usually assumed that they’re talking about things like GLTF files, which contain geometry, materials, lighting elements, animations, etc, and which Unity/Unreal can absolutely load/unload at runtime or even stream from a media server online (so they don’t have to be in the binary).
However, once you cross over into scripting code, you are in fact crossing a barrier, and it does become harder to hot-reload the way you can in a JS app. Like, the fact that Unity scripts are written in C# and have to be compiled and linked is a pretty huge impediment that you don’t face when loading almost any other kind of asset.
I’m right there with you: Hot-reloading and 3D is a thrilling combination, and tools like react-three-fiber are miles ahead of anything I’ve seen in Unity-land in terms of laying foundations for stuff like this. I’d recommend emphasizing “hot-reloading code” when drawing this distinction with Unity/Unreal folks to better get across the magnitude of what you’re looking for.
You don’t actually need this if you’re just working on graphics, as usually a flat projection is fine, but it is quite nice to work inside your own XR app while iterating on the interaction.
IMO, the main impedance towards scripted graphics facilitating hot reloading is that they are generally coded in object hierarchies whose nested state is difficult to serialise. I have found using the 2d canvas context as an immediate mode renderer alongside a single global store allows me to create workflows more similar to what one would expect with React.
I recently had more contact with gaming engines than I originally wanted and there's always this kind of community-specific vocabulary whenever you cross borders. Oh no,like in real
life.
Heh. What would be your favourite thoughts/combo here?
Sorry for not being clear on the code part. I assumed USD and the like would be the norm now. "Complex objects" is not really helpful in this context, though.
USD is fairly widely used. But it's not "code" in the sense that I mean it. It's (mostly) declarative (like HTML) so I lump it in with obj, fbx and gltf.
I am assuming code means "executable code" - I know the boundaries are fuzzy here and some file formats are Turing complete - but I guess what I'm saying is that I'm still not sure what you're asking!
For runtime loading in such an architecture, you can using an asset like TriLib.
There are many streaming ideas. Most were poorly executed. I wouldn’t generalize based on those. It is definitely the future of delivery for many reasons besides technology.
Yes. I'd love to load and re-use existing js libs as well as add code to a project and rules at runtime. I'd have loved to see WebXR being an extension of HTML instead of it being an extension to the canvas.
For Unity, I think you can just dynamically load DLLs as long as you're not on a plane form that requires AOT (iOS). Even then, for both Unreal and Unity there are many options to use scripting languages like js or lua or what have you.
Unity support for WebXR has been at the back of thier roadmap Under Consideration [1] for years and the valiant community driven efforts (@DePanther) are just too hard to keep current so lot of key Unity release improvements are missing.
Ok. will look into scripting plugins then for now, probably bridging some introspected interfaces. Would be nice if one could add/integrate existing JS libs but that's outside the Unity context.
So many great exec environments already for WASM. Is there already something available for Unity? Maybe even with a source language and compiler built in?
My focus currently is on creating code inside a running app (by the user) with references to selected Unity objects and their methods. While WebXR is great for this, the first (and sometimes only) SDK implementations for certain devices are usually in Unity.
WASM probably ist great for hotloading but would need a more complex toolset available at runtime to edit and create. Interactivity and incremental code creation would also be better in a scripting envirnment.
I got around lua so far, but bindigs seemed easy and a friend just chose it over integrating python just recently, so it seems to be getting some traction again, especially in tools and such to get a first step beyond a purely graphical UI.
If I could xr-dive into a css-3d-transformed world of objects instead of having them projected onto the 2d window right away, that would be what I was looking for in the second part of the comment above. Not sure if WebXR perspective and a 3d space is provided right now at the same level these css transforms are used.
you can calculate 2D CSS transforms which match the equivalent transforms of your WebGL scene in WebXR - as an efficient but hacky way to (for instance) do live video overlays in 3D without having to mess around importing the video texture into WebGL (assuming you don’t need occlusion or environmental effects etc).
we’re toying with this as an approach for video overlays in https://thirdroom.io, especially for underpowered devices.
Yes, I've seen similar examples. Reminded me of HW video card overlays and I hoped we would have a better solution soon.
But currently probably it what's there. Would this work as well for other HTML content, like dynamically projecting a whole DIV into/over a canvas scene that I would then be able to have positioned over some surface in VR?
It's going to be really interesting to see if Apple's headset will support WebXR. If so it will probably be the only way to get open VR/AR content on there and could drive a huge expansion in its use. Which would be a great thing because it's much nicer to work with (from my admittedly, very meagre experience) than having to build things in Unity etc.
Eventually but unlikely in the short term. Web APIs commoditize platform and hardware features. Browser content doesn’t contribute to user lock-in and takes away from exclusive apps where Apple generates revenue. We’ll probably see WebXR when hardware is effectively a commodity because competition has caught up.
On iOS, go to Settings > Safari > Advanced > Experimental Features. (Or on macOS desktop, from the Develop menu.)
Scroll to the bottom of the list.
There are 4 WebXR APIs behind a flag.
Why waste precious WebKit resources on implementing WebXR APIs in Apple's browser engine… if WebXR will hypothetically never be shipped to Safari stable?
Some time ago, I created a tech demo to display topographical terrain models in AR (the ultimate goal is to be able to show GPS tracks as an AR model on your desk), see here: https://r-follador.github.io/cubetrekXR/
It makes use of Model-Viewer, which in turn uses Scene Viewer and ARCore on compatible Android devices, and Quick-Look and ARKit on compatible iOS devices.
At the bottom there's also a WebXR implementation using Babylon.js.
Important to mention. Team at Mozilla was affected by layoffs a couple of years back and the WebXR viewer is no longer maintained. Ships an old version of the WebXR API. Don’t recommend as dev target
VR was really impressive a few years ago, it was running only on gaming computers with VR headsets. Now, with the quest 2 (far less powerfull than the gaming computers mentioned above) and web XR, it seems that developers are targeting mainly low end platforms, and so recent apps and games are rather less immersive than before mainly due to dated graphic quality, and lags when you play it on the quest (who has just a powerfull phone cpu/gpu, poor thing), or in a browser. I hope webgpu will changes that in the browser, and surely an other autonomous headset will arise with a cpu comparable to the apple M1/M2.
I love the open web and want solutions like this to win but 3D experiences built on the web seem to fall flat. Any AAA games on the web? How far is state of art native desktop 3D vs 3D through the web? Add on XR (IMU, camera, geo-tracking, AI processing) and it falls even further. It would be interesting to see some side-by-side comparisons.
Don’t have precise answers to your questions but let me reframe.
AAA games that pushes HW to the limit is a small fraction of all content. Among most popular content on Quest you have VR Chat, Gorilla Tag, Beat Saber, Job Simulator: Indie titles def not AAA that the browser would be more than capable to deliver today. https://moonrider.xyz/ for example has 60-100k VR MAUs (300k at peak on Holyday season 2021). Tech is no longer a blocker to build good WebXR content and grow an audience. Mozilla, Google and now the Meta Browser team have done excellent work to get us here
If the headset rumors are true, it would be weird if Apple didn't announce stable WebXR support at WWDC. They might be focused more on native, but good support for the Web would definitely help drive adoption for the "new" platform.
A few years ago I helped build a WebXR (Well, I think it was the WebVR specification) site for both Android and iOS, back when Motion & Orientation Access was possible on the latter platform. It worked pretty well, until it was no longer possible to access that API and we had to spend countless hours on a static fallback for iOS. The gyroscope is all you need for a relatively novel experience, ThreeJS had a VR shooter example you could easily extend, and not needing to download an app was great for getting more people to check it out.
On a VR headset you can just crane your neck and look around. On a phone or tablet it will use the accelerometer and let you use the device as a window on the virtual reality. On desktop you can use the mouse to scroll around.
This is the kind of thing that makes me lose any hope in web browsers. Normal browsing is getting worse, web apps are still unable to provide a truly native-like experience. But instead of fixing these core problems, let's add yet another corner case API...
People who say JS on the Quest 2 isn't fast enough to do good VR don't know what they are talking about. The problem is that a lot of small, indie developers only know the most naive way to implement things and then blame the platform for their lack of algorithms training.
I had originally started the project in Unity 3D. I eventually rewrote everything in WebXR because--while the naive path in Unity was faster than WebXR--the ideal path in Unity was nearly impossible to implement. I haven't done anything in Unity for about 3 years now, so maybe it has changed, but basic things like decoding textures happen on the render thread, which makes it impossible to use the Unity happy path to implement a dynamic XR app that wasn't prone to making people puke. While I was still tilting at the Unity windmill, I had a large amount of code that was just dedicated to decoding images before using them as textures, tasks Unity should have been able to handle itself, except for the fact that Unity is built by people who have never had to make a game or app themselves before.
There's a reason the loading screens on VR Chat are so long and boring--they can't slipstream live objects in because they haven't done the hard work of throwing away 90% of Unity's bullshit framework code. So they have to hide the dropped frames behind a scene fade-in/fade-out.
With WebXR, you get the full browser ecosystem to work with. Web Workers. Web Audio being off-render-thread by default. Fetch API. IndexedDB. It's somewhat popular to complain about Web APIs because some of them have some weird quirks and most of them don't agree on how to design an API, but you have no idea how much worse it can get. If you think browser app development is bad, trying making an app in Unity sometime.