Conveniently delivering interactive 3D scenes on the web
On this site, alongside text and images I can host my own audio and video content thanks to web browsers doing the heavy lifting in a standardised manner. In years gone by this might have required several plugins, but all it takes nowadays is to upload some content and choose the appropriate tag. Wonderful stuff. Frustratingly this isn't yet the case for 3D geometric data.
Until now I've been relying on embedded Sketchfab widgets to render 3D models, and while the community around Sketchfab is incredible and the tools provided are brilliantly intuitive, I have found the loading speed of their widgets to be very slow. Even with decent connection speeds they take too long to load, therefore I've been looking into self-hosted alternatives.
A model citizen
The Model Element proposal by the Immersive Web Working Group allows for USDZ models to be displayed on a web page. Thanks to Reality Converter, USDZ's are straightforward to work with and the <model/> tag allows them to be quickly displayed on a page. Even in this early stage the user experience is a positive one. Maddeningly, the tag is currently only available behind an experimental feature switch in Safari, which makes it a non-starter at least for now. It does at least offer a glimpse into a future where most of the heavy lifting is provided by the browser engine.
After looking into a few options, I have settled on using the Three.js library as an intermediate rendering solution. I am not a huge fan of gigantic third-party JavaScript libraries, and Three.js is a heavyweight in this respect, but it does work, and I am very much considering this a temporary stopgap rather than a permanent fixture.
Initial setup took longer than expected and each model requires jumping through a bunch of hoops to get them to work, but I am at least now hosting my own 3D models. Here's one I made earlier.
More customisations are to come, including full screen and augmented reality options, but this .gltf model provides a performant user experience. In testing, it displays four to five times quicker than the same model loaded via Sketchfab. Exactly what I was looking for.
File size (eventually) was also reduced compared to an equivalent .usdz file. After compressing models with Meshopt and textures with KTX2 supercompression (which turns out to be considerably less exciting that it sounds), total model size was significantly reduced. Sadly, browsers do not speak Meshopt or KTX2, which inevitably means more JavaScript (plus additional WebAssembly) that needs to be downloaded, parsed, interpreted, and run before a model can be rendered.
Going concern
Getting to this point was no fun at all. I've not yet been able to find a tool that matches Reality Converter for reliably optimising GLTF models, and Three.js is a wildly overcomplicated solution to a relatively straightforward problem.
As an aside, it is worth noting that Google's model-viewer makes an attempt to wrap the complexity of Three.js in a more user friendly system, but for whatever reason I couldn't get it to display at all on this site, and even then it doesn't solve problems around GLTF model preparation and optimisation.
Elsewhere, I'm working on an iOS app to display 3D models and the experience there is vastly better. ARKit and SceneKit already provide the frameworks required and writing code to render a model is a trivial experience. It is bewildering to witness just how far behind comparatively the omnipresent web browser is in this regard.
I remain convinced of the need for a HTML tag for 3D. A fast-loading, GPU optimised, native component that lets creators use a renderer built directly into the browser. For today's use-cases and for the next generation of high-performance virtual reality and augmented reality experiences. Time for browser developers to step it up.
