A WebGPU 3D Commerce Experiment
Over the last couple years, we’ve been writing a new version of the Babylon.js engine for WebGPU. The excitement is growing as next gen Web 3D first steps in the open are just around the corner, with a WebGPU 1.0 release aimed around Chrome 102~103. In this blog post, I’ll give a quick overview of this new Babylon.js WebGPU engine and will look at some performance improvements it could bring to 3D Commerce experiences on the Web.
Babylon.js WebGPU engine
The Journey started back in 2019, with a first experimentation of a Render Bundle Forest Demo. Babylon.js is agnostic by design and backward compatibility is paramount so, from the inception, the implementation was designed to ensure no/minimal code change for users.
Most of the engine was ported during 2020 (Render Target, Postprocesses, Shadows, Compressed Textures, Stencil buffer, Effect Layers, and many more) and was merged into the Main branch in December 2020 with the release a first version of a WebGPU Playground. In 2021, started the implementation of the new features such as Compute Shaders and Render Bundle powered Fast Paths and other optimizations. You can find more details on the WebGL+WebGPU Meet-up presentation.
What’s new: Compute Shader. It is one of the flagship capabilities brought by WebGPU. Nongraphic parallel processing (such as blur, computer vision, simulation) is now first-class. Check out this documentation page for more details and demos.
- What’s new: Fast Path. The other promise of WebGPU is to enable high-performance 3D graphic as it offers a lower-level control to the graphic resources from JavaScript. Several levels of optimization have been implemented in the new Babylon engine using Render Bundles. SnapShot Recording, the fastest mode, records draw calls during one frame and replays them for all subsequent frames. It works for mostly static scene (no pipeline change) such as e-commerce and can bring up to x10 performance increase.
3D Commerce Room Demo
In online shopping, 3D usage has accelerated over the last few years as the virtual representation it brings is often the best way for customers to discover and customize products from home. With 3D objects becoming more and more photo-realistic even in real-time rendering, assembling a virtual room full of objects while maintaining performance is a trade-off exercise for developers and 3D artists. For this blog post, I set-up myself to build my first WebGPU demo, trying to show how WebGPU could increase performances (x10 in this example) and help push the envelope in a 3D Commerce scenario.
First steps. To start using the WebGPU engine, simply go the Playground and, if your browser is supported by the WebGPU engine (Chrome/Edge Canary with WebGPU flag enabled for now), you’ll be able to switch from WebGL to WebGPU with the dropdown list on the top right corner.
Without the Playground, you simply have to update the engine creation (the initialization of WebGPU is asynchronous).
3D Room Demo. A simple room was built in Blender using a great tutorial from Polygon Runway. Once equipped with a room, I then added to it some of the glTF sample objects used by the Khronos glTF and 3D Commerce Working Groups to showcase PBR extensions and KTX2. I made sure to select some heavy objects as the goal was to show the improvement that WebGPU could bring. It was very practical to be able, out of the box, to switch from WebGL to WebGPU during the development!
Snapshot Recording — Fast Mode. The next step was to optimize the scene using the Snapshot Recording feature. It just took a few lines of code.
In the Fast Mode of Snapshot Recording, the fan and the dancing robot models were not animated anymore. To correct this, as explained in the last example of the documentation (“Animating Bones”), I simply had to ensure that all resources required to render skeletons were built by calling the skeleton.prepare method. Note that this Snapshot Fast Mode only works for mostly static scenes (no pipeline change) and that there is the possibility to update the snapshot (when adding meshes for instances).
And that was it! I actually, spent way more time building and setting-up the 3D scene than coding in the Playground, but that maybe because I’m far from being a 3D Artist (and even more a Tech Artist!). Of course, it is just the early beginning of WebGPU but I hope this will make you interested into experimenting with it.
Some useful links to go deeper:
- Full documentation on the WebGPU version of Babylon.js
- Forum to give feedback and get help
- Babylon.js WebGPU internals to deep dive into the implementation and contribute
Last but not least, a huge thank you to Alexis (aka Egveni), who is behind most of the WebGPU implementation in Babylon.js.
Thomas Lucchini — Babylon.js Team
