Developers

Streaming real-time HDR reflections to the web

Sean Looper
May 20, 2026
15 min read
Summary
  • The same source asset you'd open in your authoring application is what reaches every device, conditioned once upstream, with adaptive streaming delivering as much of that source fidelity as the device and network can support.
  • The Miris team built a WebXR car configurator with real-time HDR reflections on automotive paint, streaming to headsets, an Android tablet, and a desktop browser, with on-device reconstruction and no reliance on cloud GPUs for viewing.
  • HDR-grade material fidelity has historically only been available on devices without a reach problem (offline-rendered hero frames or server-side rendering with a cloud GPU per viewer). Delivering it on a head-mounted display, on Android devices, and in a browser, from a single delivery layer, is the engineering problem we solved.
Orange horizontal divider line

What you are watching is a 1.2GB automotive source asset streaming, simultaneously, to a desktop browser, an Android tablet, and Apple Vision Pro. Same asset. No rebuild between any of them. No app install. No cloud GPU per viewer.

The reflections on the paint are real-time HDR. View-dependent. They shift with the angle, with the environment, with the light. They are rendering on the device itself, fed by an adaptive stream.

Real-time HDR fidelity at this level on a consumer device has historically required either offline rendering or a cloud GPU per viewer. The Miris team built this configurator as an internal lab project, on the Miris spatial streaming platform, to find out if that fidelity could meet users on the devices they actually have, like a mobile phone or tablet. Spoiler, it can. 

If this is the asset problem your team has been chasing, let’s chat.

What we built 

We bought a 1.2GB high-fidelity 3D vehicle model from a major asset marketplace. We conditioned it through the Miris platform, and then we built a WebXR configurator on top of it. We did not partner with a manufacturer for this; it was an internal build, intended to stress-test the platform against one of the most demanding visual categories in commerce.

The result is a fully interactive vehicle configurator that runs in any modern browser. You can change paint colors, remove doors, and navigate through the interior as much as around the exterior. The same experience runs on desktop browsers, Android tablets, mobile phones, and headsets. 72 configurable variations (paint colors crossed with door states) are streamable end-to-end, each a conditioned variant of the same source asset, served on demand based on user input.

One asset. Any device. 

The image above is the source asset, opened in Blender. The full 1.2GB, with its original materials, geometry, and HDR environment, exactly as it came out of the DCC pipeline.

This is the same source asset, streaming live to a mobile phone, which could just as easily be streamed to a head-mounted display, a desktop browser, or an Android tablet. There is no per-platform rebuild between the Blender file and any of these surfaces. The asset is conditioned once through the Miris pipeline. From that point forward, adaptive streaming delivers as much of that source fidelity as each device and network can support.

This is the new balance point. The alternatives ask you to pick: outstanding fidelity on a few devices, or broad reach with a ton of optimization work. A great experience that reaches every user matters more than an outstanding experience that reaches a few.

Anything you can open in Blender, anything that came out of your DCC tools, anything you bought from a marketplace, the Miris platform takes through one upstream conditioning pass and turns into something that streams to every endpoint your customers might use, without an asset rebuild for each one. That accessibility cuts both ways. End users get an experience tuned to their device. The teams shipping the 3D stop running per-device optimization passes, format conversions, and platform-specific builds. The pattern is the one video already runs on: you don't upload one version of a video to YouTube for desktop and another for mobile. You upload the highest quality version, and the platform delivers the right experience to each viewer. Miris does this for 3D. Upload once, stream anywhere.

Why materials (like paint) are hard to stream

The visible quality of any automotive 3D experience comes down to how it handles materials, and specifically how it handles paint. Automotive paint has a specular response that is one of the most demanding cases in real-time computer graphics. The way light moves across a hood. The way a reflection elongates as you walk around the car. The way clear coat depth shifts the apparent color at grazing angles. These are the details a customer uses to evaluate whether a digital model is faithful to the real thing.

HDR (high dynamic range) reflections are central to this. HDR is what lets a surface render bright highlights at their real brightness, the sun on a hood, a streetlight blooming across a side panel, rather than flattened to a single ceiling value. For automotive paint, that response is what makes paint behave like paint and not like plastic.

Delivering HDR-grade reflections to a head-mounted display through a WebXR-accessible streaming pipeline is the engineering lift in this build. Until now, this category of fidelity has lived on devices that don't have a reach problem: you wait while an offline frame renders, or you connect to a server that renders the frame for you on a cloud GPU. The novelty here isn't matching that offline ceiling. The novelty is delivering true-to-source HDR fidelity to a head-mounted display, an Android tablet, and a browser, with on-device reconstruction in real time.

The headset optimization was non-trivial. Delivering material fidelity at this level to a head-mounted display means staying inside the device's compute and thermal budget while keeping reflections accurate. The Miris platform handles this in a few ways. The upstream conditioning pass identifies which surfaces on the vehicle are reflective and how reflective they are, so reflection accuracy is preserved where it matters. The streaming pipeline allocates more detail to what's close to the viewer, less to what's farther away, and renders nothing for what's behind the viewer at all. Those decisions happen together, every frame, inside the device's envelope.

The proof is in the reflections. In the video above, the reflections behave like reflections. They are view-dependent. They shift with the viewing angle. They respond to the environment. They are not baked-in highlights painted onto the surface.

No longer a choice between fidelity or reach

Every automotive brand with a serious online presence has had to answer the same question: how do we let a customer configure the car they want, at a fidelity that matches what they would see in a showroom, on the device they happen to have?

The available approaches each have real strengths. They also each have a wall.

Pixel streaming delivers excellent visual quality. Cloud GPUs render the scene, video gets transmitted, and the result on the user's screen looks close to pre-rendered. The reason brands have invested in it is that it works. The reason adoption stalls at scale is that every concurrent user requires a dedicated GPU on the back end. Costs rise linearly with traffic. A successful launch becomes a budget event. For AR and VR endpoints, round-trip latency adds head-tracking lag that's difficult to engineer away.

glTF-based web viewers solve the GPU dependency. They run on the user's local GPU, in any modern browser, with no server-side rendering at all. The cost ceiling disappears. What returns instead is a fidelity ceiling. To get a high-fidelity vehicle into a browser at acceptable load times, the asset has to be aggressively compressed. Paint reflections flatten. Material detail collapses. The surfaces that justify the price disappear at delivery.

Most brands triangulate between these. Some ship nothing at all. Doing nothing is not standing still: the brands investing in interactive 3D right now are pulling forward the moment a customer commits.

Spatial streaming is the answer that doesn't ask you to pick. Real-time, on-device rendering, like glTF, removes the cost ceiling. Adaptive delivery from a source asset, calibrated to each device and network, brings fidelity that web mesh standards can't reach. That's the architecture you've been watching.

Why WebXR

WebXR is the standards-based API that lets immersive experiences run in a browser, on any device that supports the spec, with no app install. We see WebXR as the right delivery surface for spatial streaming for the same reasons it's the right surface for any cross-device experience: no platform-specific build step, no app store review, no per-vendor SDK lock-in. The same WebXR runtime handles a desktop browser, a tablet, and a head-mounted display.

This matters most for AR and VR. High-fidelity immersive content has typically reached consumer devices through pixel streaming, which works but carries a cost ceiling and a latency cost. WebXR plus spatial streaming brings the fidelity to the user's device, rendering on local hardware, fed by a stream that adapts to the network and device capabilities in real time. No cloud GPU is allocated per session.

The format side of the same picture: Miris is OpenUSD-native at ingest. The same asset pipeline that produces a streamable vehicle for WebXR will produce a streamable vehicle for the other surfaces on the roadmap (Unity for native mobile and XR, with further engines to follow). One conditioning pass. Many endpoints.

Talk to the team

The capability behind this configurator is still rolling into our Public Beta. We're working directly with early teams to bring it into their pipelines. If you're building an automotive configurator, a virtual showroom, or any application where material fidelity and cross-device reach have been in tension, bring us the asset that's been hardest to deliver. We'll show you what spatial streaming does with it.

Reach out to us →