In 2020, OVGrid started as an experiment in building dynamic 3D virtual worlds using Babylon.js — one of the most mature WebGL frameworks available. We explored terraforming, dynamic textures, height maps, and real-time rendering. The results were promising.
OVGrid's first 3D environment tests with Babylon.js (2020)
Early terrain generation and texture mapping experiments
%[https://www.youtube.com/watch?v=_hfYsrHMAeI]
Babylon.js gave us a solid foundation: a scene graph, a physics engine, material system, and a large community. For a prototype, it was the right choice. But as OVGrid's ambitions grew — planetary-scale terrain, atmospheric scattering, thousands of instanced objects — the framework started showing its limits.
Why We Left Babylon.js
Babylon.js is an excellent framework. It even added WebGPU support. So why leave?
The answer isn't about Babylon.js being bad. It's about what happens when you need total control over every GPU instruction.
Bundle Size and Dependencies
A full Babylon.js build adds significant weight to your application. For a project that targets instant browser access with zero downloads, every kilobyte matters. OVGrid needed to be lean — a PWA that loads in seconds, even on mobile.
GPU Pipeline Control
When you're writing custom atmospheric scattering shaders, cascaded shadow maps with 4 layers, and GPU-driven terrain instancing, you need direct access to the WebGPU pipeline. Working through a framework's abstraction layer means fighting against it when your needs diverge from its assumptions.
The Abstraction Tax
Every abstraction has a cost. Babylon.js manages its own render loop, its own resource lifecycle, its own state. When you need a Floating Origin system that keeps the camera at (0,0,0) and offsets the entire world in Float64 — or when you need to reduce terrain draw calls to one single call per frame — you need the GPU to do exactly what you tell it. No middleware.
Philosophy: Pure JavaScript, Zero Frameworks
OVGrid's philosophy aligns with a broader conviction: the best code is the code you fully understand and control. No framework updates breaking your build. No dependency chains. No black boxes. Just JavaScript, WGSL shaders, and the WebGPU API.
The Migration
The transition wasn't a weekend refactor. It was a deliberate, incremental process.
Phase 1 — Custom Render Pipeline. We replaced Babylon.js's render loop with a direct WebGPU pipeline. This alone gave us the ability to control exactly which compute and render passes execute per frame.
Phase 2 — Shader Rewrite. Every shader was rewritten in WGSL from scratch. Atmospheric scattering, terrain rendering, vegetation instancing — all hand-tuned for OVGrid's specific needs. No generic material system overhead.
Phase 3 — Floating Origin. The camera stays at (0,0,0) in GPU space. World coordinates use Float64 on the CPU, and only relative offsets are sent to the GPU. This eliminates the floating-point jitter that plagues every large-scale WebGL application.
Phase 4 — GPU-Driven Instancing. Terrain chunks, vegetation, and objects are rendered with a single instanced draw call per category. The GPU decides visibility, LOD, and placement.
Phase 5 — Modular Architecture. Using Bun as the bundler, we split the UI into lazy-loaded modules. Configuration panels load on first interaction. The main bundle stays minimal.
The Results
The numbers speak for themselves:
- 120 FPS sustained during planetary traversal — from ground level to orbit
- One draw call for all terrain chunks per frame
- Sub-second initial page load as a PWA
- Zero dependencies — no node_modules, no framework updates, no breaking changes
- Full mobile support — the same codebase runs on desktop and mobile browsers with WebGPU
When Frameworks Make Sense
This isn't an anti-framework manifesto. Babylon.js is the right choice for many projects — games, product configurators, architectural visualization. If your project fits within a framework's model, use it.
But when you're building a planetary-scale virtual world that needs to push every boundary of what the browser can do, the framework becomes the ceiling. Removing it becomes the unlock.
What's Next
OVGrid continues to evolve. The migration to native WebGPU was the foundation. On top of it, we're building:
- GenosDB integration for P2P identity and real-time world state
- Polygon blockchain for OVG tokens and ERC-1155 metaverse assets
- Ready Player Me avatars for cross-platform identity
- Cascaded Shadow Maps with 4-layer precision up to 10km
The browser is no longer the limitation. It's the platform.
Written by Esteban Fuster Pozzi (estebanrfp), creator of GenosDB and OVGrid.
Top comments (0)