Skip to content

Browser rendering just had its best month ever

By Oleg Sidorkin, CTO of Cinevva

While the game industry spent March arguing about AI at GDC, the browser rendering stack shipped five years of progress in four weeks. Nobody held a press conference. Nobody posted a hot take. Five separate things happened that collectively changed what "browser game" means.

Babylon.js has been pushing browser rendering forward for years. Version 9.0 took the biggest leap yet.

What shipped in March 2026

Babylon.js 9.0 launched with clustered lighting, a rendering technique that handles hundreds of dynamic lights in a scene without killing performance. Until now, this was an AAA engine feature. The release also includes volumetric lighting with realistic light scattering, textured area lights for effects like stained glass and LED displays, and a node-based particle editor. All of it runs on both WebGPU and WebGL 2.

PlayCanvas v2.17 shipped GPU-driven Gaussian Splatting sorting on WebGPU. Gaussian splatting, the technique that turns photogrammetry captures into real-time 3D scenes, was a research paper two years ago. Now it's running in a browser engine with GPU acceleration for the sort pass.

Three.js r183 renamed its PostProcessing module to RenderPipeline. That sounds like a minor API change, but the naming matters. "Post processing" is something you tack onto a hobby project. "Render pipeline" is production infrastructure. The Three.js team is signaling that the library is ready for serious, structured rendering architectures.

Chrome 146 added WebGPU Compatibility Mode, which means older GPUs that don't support the full WebGPU feature set can now use WebGPU through a reduced-capability path. The install base for WebGPU just expanded dramatically.

The W3C published WebGPU as a Candidate Recommendation Draft. This is the formal step toward it becoming an official web standard. WebGPU is no longer experimental. It's on the standards track.

Why this month is different

Any one of these releases would be noteworthy. All five happening in the same month creates a compounding effect.

Five years ago, "browser game" meant a 2D casual game, maybe with some Canvas effects if you were ambitious. Three years ago, you could do basic 3D with careful optimization. A year ago, WebGPU started landing in production browsers and the ceiling began to rise.

But March 2026 is when the gap between native and browser rendering moved from "significant" to "narrowing fast." Clustered lighting was something you needed Unreal or Unity for. Gaussian splatting was something you needed a research lab for. Production-quality post-processing pipelines were something you needed a custom engine for. All three are now shipping in open-source browser engines that anyone can npm install.

Three.js Water Pro running on WebGPU. This is a browser.

What I think happens next

We've been betting on browser-first game delivery at Cinevva since the beginning. The thesis was always that the rendering gap would close because the web platform iterates faster than native engines. WebGPU took longer than I expected, but the convergence is now happening on schedule.

The practical effect is distribution. A game that runs in a browser doesn't need a download, an install, or a platform approval process. It loads from a URL. That's always been the browser's advantage, but it only matters when the rendering quality is good enough that developers actually choose it.

We're past that threshold now. Not for every game. Not for open-world AAA with ray tracing. But for an increasingly large class of games that include real-time 3D, dynamic lighting, particle systems, and photogrammetric assets, the browser is a viable target. And unlike native platforms, there's no 30% platform tax on the other end.

The question was never "will browsers catch up." It was "when." March 2026 answered it.


Related: