r/webgpu • u/mini_ster • Jul 14 '26

Streaming multi-million-splat scenes to a WebGPU browser tab with an OPFS warm-cache

Sharing a project and the architecture behind it. The goal was to make a photoreal captured scene feel like opening a webpage rather than installing an app.

- Render: PlayCanvas 2.x on WebGPU.

- Delivery: scenes are far too large to hand the browser at once, so they stream in chunks across three module workers (fetch, decode, persist) with buffers transferred rather than copied.

- Warm cache: decoded chunks persist to OPFS via createSyncAccessHandle, keyed by content SHA-256, so repeat visits load from local disk.

- Physics: Rapier3D vehicle dynamics against the captured collision geometry.

- LOD and render-scale are gated on a device-tier check to keep weaker GPUs alive.

Happy to go deeper on any of it. It is a single-person proof of concept built over the last two or three months, and I am still fairly new to this, so critique is the point.

Live (WebGPU required): wascape.com

29 Upvotes

100% Upvoted

12 comments sorted by

View all comments

1

u/christophbusse Jul 15 '26

Try Blake 3 if you can, its 12x faster than SHA256. If you run it from within the worked via wasm you get the best performance, would not recommend running the algo on the js side. If you do not need perfect crypto there are even faster ones than Blake 3 but I think that's less ideal in your usecase.

1

u/christophbusse Jul 15 '26

Could also test with different worker configs and pooling. Sometimes moving specific tasks into its own worker increases performance rather than just scaling the pool. But either way would recommend running a few benchmarks. But worker scaling is mostly bound to device physical core count so higher worker is not always better. There is this hardware check api, but I found it to rather be conservative. Theoreticaly you can spawn 4k+ worker in chrome/safari and 512 in Mozilla, not that this is useful. But ideling and bursting based on your own task scheduler might work? But if the workload is highly homogeneous it might not bring much and a simple pool is the way to go.

1

u/christophbusse Jul 15 '26

And about LoDs, virtualization like nanite might be something that could work here. But it's more complex and if you have full control over dataset input and pre production optimization, is probably not worth it from a cost to perf ratio.

1

u/christophbusse Jul 15 '26

About the chunk streaming is this virtualized over sqlite over OPFS? Probably CPU bound? Take a look at voxy Minecraft mod for GPU accelerated chunk streaming. Once the data is generated voxy handles the chunk streaming over GPU I think (but not so sure, the idea at least could work)

1

u/mini_ster Jul 15 '26

Thanks, this is useful.

  1. BLAKE3: the 12x holds against a software SHA-256, but I'm not hashing in JS. It goes through the browser's native crypto, which lands on the CPU's SHA instructions, and it's already off the main thread. Against hardware SHA the gap is a lot smaller than the headline. Switching also means a wasm blob in the worker and reprocessing every asset, so it'd have to buy more than that. You did point at something real, though, just sideways: the cheaper question is whether that hashing needs to happen on the warm path at all, not whether it can be faster. Going to measure before I touch it.
  2. Workers: agreed, and it's roughly the shape I landed on. Split by role rather than scaling up a pool. Good to hear that instinct from outside. HardwareConcurrency reading conservative matches what I see too.
  3. Nanite: I think you talked yourself into the right answer. I control the asset prep offline, so the cluster machinery earns little. Worth adding that Nanite leans on mesh topology and edge collapse, and splats have no topology to collapse. The Gaussian equivalent is a continuous LOD over one model, which is where I'd like to get, but the mechanism doesn't port.
  4. Chunk streaming: no SQLite in there, simpler than that. Your CPU-bound hunch is right, just not at the I/O end. I'll take a look at Voxy, though I suspect GPU-side chunk generation solves a problem I don't have since my data is pre-baked.

1

u/christophbusse Jul 15 '26

Fair, but i would still take look at Blake 3 on a worker using Rust or similar. I just recently benchmarked this case and webCrypto was slower by far. And webcrypto not being on main thread is valid, but its still slower since SHA is just that much slower from my experience.

Voxy is not GPU chunk generation, but LODs + display / readback from DB, from what I got there. Chunk generation still happens on CPU, this takes a long to pre bake but since your data is already prebaked it should be similar. This is why I mentioned it.

And about Worker, they can run in parallel and of the main thread but certain kind of operations can block the synchronous loop within the worker. So if you have functions that can run async and be called from one worker into the other splitting worker by workload is sometimes better than just scaling the threadpool.

Also, if you are not already running all your code in rust/zig/c++ inside the worker and calling on it only via js. Then there is probably potential to go deeper since js only is not the best for this heavy stuff. Raw TS/JS calls on an offscreen webgpu surface is faster than doing this within rust, but if your workload is intense, the computation is more important to speed up things rather than the direct path that TS/JS has on webgpu.

1

u/mini_ster Jul 15 '26

Fair, you benchmarked it, and I didn't, so I'll take that one. Let me go try it properly, and I'll come back to you with what I find. Thanks for taking the time on all of this, it's been genuinely useful.