We made a game where your snake is the paddle and the bricks fight back. It shipped on web, mobile, and PC. It took two of us about three days. On and off, not crunching. And it's fun to play.

The mashup nobody asked for

Snake is about growth and spatial awareness. Arkanoid is about reflexes and angle prediction. They come from completely different design philosophies, and mashing them together sounds like the kind of pitch that gets politely declined.

But A Breaker Belt makes it work. You're a cosmic serpent, a living arc of neon current threading through an asteroid field of breakable blocks. Your head is the paddle. Your growing tail is both your greatest weapon and your most constant threat. The orbs ricochet off your body to shatter bricks, but one wrong turn into your own tail and you're done.

It's the kind of weird cross-genre experiment that usually dies before anyone gets to play it, because the development cost of finding out whether a weird idea works has traditionally been measured in months. Here it was measured in afternoons.

What actually shipped

The scope is what makes this interesting. This isn't a game jam prototype with placeholder rectangles and no sound.

The game runs 50 waves deep. That's not 50 variations of the same brick wall. The formations evolve from gentle onboarding arcs into fortress rings that demand angled shots through side gaps, then into layered diagonal mazes with one-tile-wide openings that require precision steering. Explosive bricks blow their neighbors apart. Phantom bricks flicker in and out of existence. Regenerating bricks heal back after you break them. Portal bricks teleport your orbs across the arena. Gravity wells bend your shots into slow, curving hymns. Laser emitters sketch red lines across the void. Mimic bricks look harmless until they decide they're not. By wave 15, you're navigating something that feels less like a puzzle and more like a living system that's learning your habits.

The music isn't a loop. It's a reactive soundtrack that builds with your gameplay. Bass, lead synth, pad, drums all running in E minor, and as the action intensifies, additional layers fade in. When things calm down between waves, ambient pads take over. The music breathes with you. A dedicated composer would spend weeks tuning that kind of responsiveness. Here it was part of the creative flow.

The sound effects aren't samples pulled from a free pack. Every brick shatter, orb bounce, and collision is synthesized in real time. Different pitch for head contacts versus tail contacts. Warm reverb for the spacey feel. When you chain a combo, the audio tells you before the screen does.

And then there's the storytelling. Each wave opens with a narrative beat delivered by AI-generated voice. Wave one: "They call it the Breaker Belt: a ribbon of engineered debris that circles the old star like a warning." By wave 38: "The Belt stops feeling like a wall and starts feeling like a mind. It tests not your reflexes, but your habits." It's 50 chapters of cosmic mythology that makes you care about why you're a snake breaking bricks in space.

The backgrounds evolve too. Early waves are calm indigo starfields with soft meteor rain. By mid-game, aurora bands and nebula clouds appear. Late game drops you into Ion Storm territory with sharp cyan streaks against near-black space. The game communicates progression through atmosphere as much as difficulty.

All of this runs on keyboard, gamepad, or touchscreen. Published to web, mobile, and PC from one codebase.

The team that wasn't needed

A game with this depth would typically need a game designer, a couple of programmers, an artist, a sound designer, a composer, a level designer, a narrative writer, and QA. Eight or nine people. Three to six months of coordinated work. Standups, Jira tickets, asset pipelines, platform-specific debugging.

Two of us made this in a long weekend on the Cinevva Engine.

The talent required didn't change. The ratio between creative intent and implementation overhead did. The time was spent deciding what the game should feel like, not fighting tools to make it happen.

Why this matters if you make things

The interesting question isn't whether AI tools can help make games faster. That's been answered. The interesting question is what happens to ideas that used to be too risky to try.

"Snake but you're the paddle in an Arkanoid arena" is not something a producer greenlights. A few indie devs have tried variations on itch.io (BreakSnake, SnakeOut, Snake Break), but they're all small game jam experiments. The genre fusion has never been given a real production pass with reactive music, AI narration, dozens of brick types, and 50 waves of escalating design. In traditional development, that kind of polish on a risky concept gets killed in a meeting before anyone writes a line of code.

When trying something weird costs an afternoon instead of a quarter's budget, the strange ideas get built. Some of them turn out to be genuinely good. A Breaker Belt is one of those.

Play it. Or make your own.

A Breaker Belt is playable right now on web, mobile, and PC. If it makes you want to build something, the Cinevva Engine is free to use. Describe what you want, iterate on what comes back, ship when it's ready. The music, sound effects, art, and 3D models are all built in.

Your weird game idea might be three days away from existing.

Play A Breaker Belt | Build your own game | Browse community games

A small team at Cinevva just published one of the most transparent engineering journals in recent game-dev memory: a 12-part series documenting their attempt to build a multiplayer open world that runs entirely in the browser. No download. No app store. Just a URL.

The project spanned 24 technical experiments they call "spikes" -- short, focused prototypes designed to answer one risky question each. Every spike shipped with live source code you can open and run in your browser right now. The series was written by Oleg Sidorkin, CTO and co-founder of Cinevva, and it reads less like marketing and more like a field journal from the frontlines of what browsers can actually do in 2026.

What makes the series worth reading -- even if you never plan to build terrain systems -- is the method underneath. It's a case study in how to de-risk an ambitious project before you've committed to anything expensive.

Starting with the hardest question first

Most open-world projects die in a predictable sequence. First you get a beautiful concept. Then a pretty scene. Then you discover that your frame budget was already spent before gameplay existed.

Cinevva's team inverted the order. Their first spike was deliberately ugly: a 512-meter terrain mesh, 500 instanced objects, procedural height noise, a water plane, and fog. No shadows, no beauty pass. The only question was whether a browser could hold a stable frame rate while the camera moved through it.

It could. And that "yes" established something Sidorkin calls a "baseline contract" -- a measured reference cost for a minimal scene that every subsequent feature had to justify itself against. If a new effect looked great but blew the frame budget, it didn't ship. Not yet, anyway.

That kind of discipline sounds obvious. In practice, it's rare in fast-moving prototype environments where everyone is excited about the next visual win.

The physics gamble

The second experiment tackled an architectural debate that divides browser game developers: should physics run on the main thread, where it's simpler, or in a Web Worker, where it can't block rendering?

Worker-based physics is cleaner on paper. In practice, the fear is latency. Every input event has to cross a message boundary twice: once to reach the worker, once to bring back the result. If that round trip is too slow, pressing a key and seeing your character move will feel sluggish.

Sidorkin's team integrated the Rapier physics engine (compiled from Rust to WebAssembly) in a dedicated worker, wired up the message pipeline, and measured. The overhead was negligible. Controls still felt immediate. But the team was careful to note that they'd validated one specific scenario, not a universal rule. When GPU pressure and streaming complexity changed later, assumptions would need rechecking.

The boring spikes that saved the project

Part three of the series has no screenshots. It covers three experiments that looked unglamorous but carried product-level consequences.

The first tested whether Cloudflare Durable Objects could handle real-time position broadcasts at game-like tick rates -- the multiplayer backbone. If this had failed, the entire network architecture would have needed early sharding rather than single-island ownership.

The second validated a mobile quality profile: not a desktop preset renamed, but an explicit low-cost rendering path from the same terrain baseline. The question was whether the world could remain readable and responsive under mobile GPU constraints without rewriting the renderer.

The third evaluated whether AI-generated behavior scripts for creator workflows would be reliable enough for production use.

None of these produced demo reels. All three set hard boundaries that shaped every architectural decision afterward. Sidorkin writes that these "unflashy spikes changed architecture faster than visual spikes did."

Streaming: where pretty projects fall apart

You can hide a lot in a still frame. You can't hide a 40-millisecond stutter when crossing a chunk boundary while running.

The team tested streaming before building advanced terrain, deliberately separating concerns. Spike 6 validated neighborhood chunk loading with simple content. Only after that clean signal did Spike 11 introduce compressed heightmap streaming with progressive refinement -- loading terrain at 17-sample resolution first, then 33, then the full 65-sample grid.

The sequencing mattered more than they expected. Had they started directly with compressed height chunks, every hitch would have been ambiguous. Was it a decode issue, a texture upload stall, or a geometry update problem? Testing simple streaming first eliminated one entire category of uncertainty.

A practical lesson emerged: measure upload stalls directly, not through average FPS. Averages hide frame spikes, and frame spikes are what players actually feel.

The visual budget wars

Three separate experiments attacked rendering costs in isolation rather than bundling them. Vegetation density and wind animation. Multi-layer terrain materials with triplanar mapping for cliff faces. Cascaded shadow maps under realistic terrain load.

The vegetation spike revealed that batching instances into fewer meshes mattered more than reducing per-blade polygon count. The material spike found that triplanar projection on vertical surfaces was worth the GPU cost, but adding a fifth texture splat layer wasn't. The shadow spike determined that three cascades at 1024 resolution delivered acceptable contact shadows without exceeding 2 milliseconds of GPU time.

The team adopted a blunt rule: a feature moves forward only if it can explain its cost with measured frame-time data. That constraint, set early, made later architectural decisions around volumetric terrain and clipmaps significantly cleaner.

The pivot that changed the project's trajectory

Before Spike 10, the team's mental model was "bigger world means more geometry." After Spike 10, it became "constant geometry budget, camera-centered ring updates."

Geometry clipmaps -- concentric rings of terrain centered on the camera, each ring progressively coarser -- meant the triangle count stayed roughly constant regardless of draw distance. The practical trick was geomorphing at ring boundaries: smoothly blending vertex heights in the shader so that the shift between resolution levels is invisible in motion.

A subtle lesson came from testing methodology. Clipmaps look fine in screenshots. They reveal their artifacts only under sustained camera movement through ring boundaries. The team spent time running constant-speed traversals and watching for temporal noise. "Screenshots lied," Sidorkin writes. "Motion told the truth."

Going underground

Heightmaps can't represent caves. They store one elevation value per point on a grid. The moment you need tunnels, overhangs, or carved rock faces, you need volumetric terrain.

Spike 12 implemented marching cubes on the GPU using WebGPU compute shaders, extracting triangle meshes from a 3D signed distance field. Four 64-cubed chunks ran simultaneously with per-frame mesh updates from animated SDF edits. The compute shader handled everything -- evaluating the field, classifying cells, emitting vertices -- without any CPU readback.

The challenge wasn't making it work. It was making it work alongside everything else. Integration with Three.js's scene graph, buffer lifecycle management (WebGPU buffers can't be resized), fence handling to avoid destroying GPU resources still in flight -- the series devotes two full parts to what they call "incremental hardening," the unglamorous process of adding one capability at a time and verifying the previous layer still functions after each addition.

The seam nightmare

The most technically harrowing section of the series spans Parts 9 through 11, covering what happens when terrain chunks at different resolutions meet.

When a high-detail chunk sits next to a low-detail chunk, their independently generated meshes don't align at the boundary. The result is visible cracks, flickering edges, and T-junctions where light bleeds through. The Transvoxel algorithm solves this with special transition cells that bridge resolution differences -- but implementing it correctly across all chunk configurations, with consistent winding order, proper buffer management, and accurate draw ranges, consumed six separate experiments.

The team's most memorable debugging story: two days chasing a seam artifact they blamed on transition logic. The actual culprit was stale data. The GPU compute shader wrote N vertices into a buffer, but the draw call was still configured to render N+M vertices from the previous frame. Those extra vertices contained garbage that produced flickering razor-thin triangles. One line fix: clip the draw range to the atomic counter's active vertex count.

"Rendering bugs often masquerade as meshing bugs," Sidorkin observes. "The geometry was correct the whole time."

From chaos to governance

After the seam battle, the team replaced ad-hoc chunk behavior with an explicit policy system. A central function now decided each chunk's LOD level, rendering mode (heightmap or marching cubes), and which faces needed transition cells. Distance rings determined the base LOD. An adjacency constraint ensured no two neighboring chunks differed by more than one resolution level. An edit bitmap kept volumetric chunks in marching-cubes mode regardless of distance if they contained creator modifications.

Color-coded debug overlays -- green for heightmap chunks, blue for marching cubes, orange for transition faces -- turned "I saw a bug somewhere near that ridge" into "the bug appears at position (142, 12, -67) facing northwest."

"Policy didn't reduce complexity," Sidorkin writes. "It organized complexity."

What it adds up to

The final spike combined clipmap rings, per-fragment sky fog (sampling the actual skybox color in the direction of each terrain fragment), and Three.js module wiring into a unified demonstration. The result is a terrain system that layers near-field volumetric editing, mid-field heightmap chunks, and far-field clipmap rings under a policy layer that governs mode, LOD, and transitions.

The series closes with lessons Sidorkin says he'd repeat on any future project:

• Start with risk spikes before feature work. Kill the "can we even do this?" questions before investing in content pipelines.
• Freeze known-good baselines before integration jumps. The day spent establishing a clean checkpoint saves multiple days bisecting regressions later.
• Force policy and observability before optimization marathons. Named conditions with trigger rules beat mystery bugs every time.
• Test under motion, not screenshots. Pops, flicker, and streaming hitches all hide in still frames.
• Measure per-feature frame time, not average FPS. Averages hide the spikes that users actually feel.
• Publish the messy parts. The wrong turns, the ghost hunts, the two days blaming the wrong system. Those are the parts people can actually learn from.

Why this matters beyond Cinevva

The series is significant for three reasons that extend past one company's terrain pipeline.

First, it demonstrates that WebGPU compute shaders, WebAssembly physics, and edge-deployed Durable Objects have crossed a threshold. A multiplayer open world with volumetric terrain, real-time editing, and streaming LOD is architecturally viable in a browser tab in 2026. That was not true two years ago.

Second, the spike methodology -- small, focused experiments that each answer one risky question with live, measurable results -- offers a template for any team attempting something that might not work. The discipline of measuring before committing, of establishing baselines before integrating, of naming edge cases before optimizing, applies far beyond terrain systems.

Third, the radical transparency is the point. Publishing source code for all 24 experiments, including the dead ends and the two-day debugging detours, makes this more than a technical blog. It's a public engineering notebook that treats the reader as a colleague rather than a customer.

The full series is available at Cinevva's blog, with every spike running live in the browser.

Cinevva is a game creation platform where anyone can build, publish, and share games using AI-powered tools. The open-world browser series was written by Oleg Sidorkin, CTO and co-founder.

Article: https://vio-202020.medium.com/de-risking-an-ambitious-project-before-committing-to-anything-big-like-an-online-open-world-c94a7c05ee06 Blog Series: https://app.cinevva.com/blog/2026-02-25-open-world-browser-series-guide

LinkedIn (Cinevva Company Page)

Schedule: Tuesday March 10, 10:00 AM ET Image: https://app.cinevva.com/img/blog/open-world-browser-120fps.png

Our CTO Oleg Sidorkin just published the full engineering journal behind building a multiplayer open world that runs entirely in a browser. No download. No app store. Just a URL.

24 experiments. 12 parts. The series documents the full sequence -- wins, dead ends, and recovery patterns -- with live source code for every experiment.

• The first experiment was deliberately ugly -- measuring whether a browser could even hold a stable frame rate before investing in anything pretty
• Physics in a Web Worker with Rapier compiled to WebAssembly -- and whether the input lag fear was justified (it wasn't)
• The "boring" spikes that set hard boundaries on network architecture, mobile constraints, and AI behavior reliability
• Streaming chunk transitions that expose 40ms hitches no screenshot can hide
• GPU-driven marching cubes via WebGPU compute shaders for caves and overhangs
• A six-experiment seam nightmare debugging Transvoxel transitions across mixed LOD chunks
• The two-day bug hunt where the geometry was correct the whole time -- the draw call was reading past the buffer

The methodology matters as much as the tech. Start with risk. Freeze baselines before integration jumps. Measure per-feature frame time, not averages. Test under motion, not screenshots.

Whether you're building games, tools, or anything ambitious in the browser -- the spike-based de-risking approach transfers.

#gamedev #WebGPU #webdev #softwareengineering

X (Twitter) Thread — @CINEVVAGames

Schedule: Tuesday March 10, 9:00 AM ET Note: X/Zapier integration is text-only (no image field). Post images manually via X app after thread is live.

Tweet 1 (main)

Our CTO Oleg Sidorkin (linkedin.com/in/osidorkin) just published something unusual -- the full engineering journal behind building a multiplayer open world that runs entirely in a browser tab.

24 experiments. 12 parts. Every spike ships with live source code.

https://vio-202020.medium.com/de-risking-an-ambitious-project-before-committing-to-anything-big-like-an-online-open-world-c94a7c05ee06

🧵

Tweet 2

The methodology matters as much as the tech:

• First experiment was deliberately ugly -- just measuring if a browser can hold a stable frame rate
• Physics in a Web Worker with Rapier compiled to Wasm
• GPU marching cubes via WebGPU compute shaders for caves
• A two-day bug where the geometry was correct the whole time

No install. No app store. Just a URL.

Tweet 3

Whether you're building games, tools, or anything ambitious in the browser -- the spike-based de-risking approach transfers.

Full series with all 24 live experiments: https://app.cinevva.com/blog/2026-02-25-open-world-browser-series-guide

#gamedev #WebGPU #webdev

Instagram (Cinevva)

Schedule: Tuesday March 10 (or post anytime — Instagram is less time-sensitive) Images (carousel):

1. https://app.cinevva.com/img/blog/open-world-browser-120fps.png
2. https://app.cinevva.com/img/blog/open-world-chunk-streaming.png

No download. No app store. Just a URL.

Our CTO Oleg Sidorkin published the full engineering journal behind building a multiplayer open world that runs entirely in a browser.

24 experiments called "spikes" -- each one designed to answer a single risky question before committing to anything expensive. Every experiment ships with live source code.

What stood out:

→ The first experiment was deliberately ugly. No shadows. No beauty pass. Just: can a browser hold 60fps while a camera moves through 500 objects? → Physics running in a Web Worker with Rust compiled to WebAssembly -- and the input lag everyone feared didn't show up → GPU-driven marching cubes via WebGPU compute shaders for caves and overhangs → A six-experiment nightmare debugging seams between terrain chunks at different resolutions → The two-day bug hunt where the geometry was correct the whole time -- the draw call was reading past the buffer

"Screenshots lied. Motion told the truth."

The spike methodology applies far beyond games. Start with risk. Measure before committing. Publish the messy parts.

Full series link in bio.

. . . #gamedev #gamedevelopment #webdev #webgpu #indiedev #indiegames #browsergames #openworld #javascript #threejs #webassembly #softwareengineering #techblog #buildinpublic #cinevva

For: Oleg Sidorkin
Re: app.cinevva.com/blog/2026-03-04-sketch-to-animated-3d-character
Checked against: cinevva-site repo (marketing site + worker)

Verified ✓

• Tool names (Image Generator, Video Generator, 3D Model Generator) and link /tools/hunyuan3d match the codebase.
• Author (Oleg Sidorkin, CTO) is correct.
• Video workflow: Start + end frame interpolation, 9:16, 3–15 s duration, and storyboard mode are all supported.
• 3D pipeline: Hunyuan3D and "3D Model Generator" are correct; auto-rigging (Tripo) and "upload GLB → rigged model + animation library" match the implementation.
• Cinevva Engine and "Reflects early 2026" are accurate.

Correction needed

"Seedance 1.5 Pro" — In this repo, video is implemented with Kling 3.0 Pro (fal.ai), not Seedance 1.5 Pro:

• worker/src/genai/fal-video.ts uses fal-ai/kling-video/v3/pro/...
• worker/src/index.ts tracks cost as model: 'kling-3.0-pro'
• tools/video.md says: "Generate short AI videos from text or images using Kling 3.0 Pro"

The API/product name is "seedance" (e.g. /genai/seedance/generate), but the underlying model is Kling 3.0 Pro. Seedance 1.5 Pro is a different model (ByteDance). Public sources often cap Seedance 1.5 Pro at ~10 s; 15 s is supported for Kling here.

Recommendation: In the article, name the video model "Kling 3.0 Pro" (or e.g. "Video Generator (Kling 3.0 Pro)") so it matches the marketing site and docs. If the app backend actually uses Seedance 1.5 Pro, align the app copy and tools/video.md so they describe the same model.

Not verifiable in repo

Cubcoats, Kali the Kitty, Mimi Chao, and related business claims are external; not checked.

Taking you to spike {{ spikeId }} in the Game Creator. If you're not redirected, open it here.

Open the Game Creator.

← Back to series guide

By Mariana Muntean, CEO of Cinevva

The games industry made about $195.6 billion in 2025. Its best year ever. In the same stretch, roughly one in three developers lost their job.

Read those two sentences again. They shouldn't be able to coexist, and yet here we are. If you got cut in the last two years, you already know the math doesn't feel like a downturn. It feels like being told the boat is fine while you're the one going overboard.

I've been an indie dev. I've watched friends post the "open to work" banner three times in eighteen months. So this isn't a hot take from the sidelines. Let's look at what actually happened, and then the part that matters most if you're job hunting right now: what's genuinely getting people rehired.

The numbers are worse than the vibe

The layoff wave started in 2022 and never really stopped. It's not one bad quarter. It's a four-year structural reset.

That's roughly 44,000 to 55,000 jobs gone over the period, depending on whose tracker you trust (Wikipedia, GamesBeat). The 2026 State of the Game Industry report from GDC, which surveyed more than 2,300 professionals, found that 28% of developers globally lost their job in the past two years, and 33% in the US (GamesIndustry.biz). Half said their current or most recent employer ran layoffs in the last twelve months.

North America took the worst of it. Amir Satvat's workforce tracking, which is the closest thing this industry has to a running census, shows the regional workforce shrank while the global headcount barely moved. About 19% of North American games workers were affected (GamesBeat).

Here's the stat that explains why the job search feels impossible even after hiring "recovered." Satvat estimates around 288,000 people were looking for games work over this window. Recent grads, laid-off veterans, and career changers, all applying into the same narrow set of openings. When you send a resume into a job post now, you're not competing with a dozen people. You're competing with a stadium.

Why a record year still meant pink slips

The revenue didn't disappear. It concentrated. A shrinking number of live-service giants pull an outsized share, which means fewer new bets, fewer new teams, and fewer of the mid-size projects that used to absorb talent. Private investment in games dropped by more than half in 2025 (Outlook Respawn). Studios responded the way studios do: cancel projects, trim budgets, move work to contractors.

So the profit is real, and the pain is real, and they're pointing at the same cause. That's cold comfort when you're the one refreshing your inbox, but it tells you something useful. This isn't a market waiting to snap back to 2021. The people getting rehired aren't waiting for that either. They're adapting to how hiring actually works now.

The job market has an authenticity problem

Talk to anyone who screens candidates today and you'll hear the same complaint. They're drowning. Job posts pull hundreds of applications in hours, and most of them read like the same person wrote them, because in a sense the same tool did.

Recruiters told TechRound the hard part isn't spotting AI use, it's that the flood of "well-optimized, low-context content" makes it nearly impossible to find the person who actually gets the role (TechRound). LinkedIn itself now says it detects generic AI-written content around 94% of the time and quietly limits how far it spreads (TechRound).

Flip that around and it becomes the best news in this whole article. When everything sounds the same, being specific is a superpower. In a feed of identical polish, the human who shows real work and real thinking doesn't just stand out. They're the only signal in the noise.

Proof beats polish, every single time

For game roles specifically, the thing that moves the needle isn't a prettier PDF. It's evidence someone can experience. A 12-year recruiter put it bluntly: a playable build or a demo reel does more for you than almost anything else on your application.

That's the shift. A resume tells a recruiter you understand design. A playable slice lets them feel it in 30 to 90 seconds. You can't fake a working mechanic the way you can fake a bullet point. You can't fake a walkable level, a live shader, a rig that actually moves, or an interactive audio cue mapped to a real scene. Interactivity is proof that survives scrutiny, because behind it is a person who can defend every decision.

And that last part is what recruiters are really testing. The tell they use to catch AI-padded portfolios is simple: ask about process, not output. Someone who generated a case study can describe what it says, but not the decisions behind it. So the strongest portfolios in 2026 all carry the same four things:

That "kept, changed, rejected" line is the one most people skip, and it's the one that proves taste. Taste is the hardest thing to fake, and it's exactly what a studio is buying: someone who can pick the right idea out of ten plausible ones. Skip the "I learned so much" wrap-up. Show the call you made and why it served the player.

A word about AI, because this industry has earned the right to be angry

I run a platform that uses AI tools, and I'm not going to pretend the tension isn't there. The same GDC survey found that 52% of developers now think generative AI is having a negative impact on the industry, up from 18% two years ago, and the strongest opposition comes from artists, writers, and programmers (GamesIndustry.biz). When you've just been laid off and told a model might do a slice of your old job, "just use AI for your portfolio" is a slap, not advice.

So I'll say it plainly. Nobody gets hired by handing a recruiter something a machine generated and they can't explain. The work has to be yours. Your decisions, your craft, your ownership. If you did use a tool somewhere in a project, say so, and show your judgment on top of it: what you kept, what you threw out, why your call was better for the player. Hiring managers trust the person who treats a tool like an intern that needs direction, not the person hiding behind it. Honesty about your process reads as professionalism, and professionalism is often just "I thought about the consequences before I published."

Where to put the proof

One practical thing, since so many of these conversations start on LinkedIn. The feed punishes outside links hard, but your profile's Featured section doesn't. That's the one spot that turns a link into a clean preview card with no penalty, and it sits right at the top of your profile where recruiters look first. Pin three to five things, best work first, and remember most people are viewing on a phone. Lead with the item someone can open and experience in seconds.

Keep it fast and keep it honest. A demo that loads in under two seconds and shows one clean idea beats an ambitious project that stutters or 404s. Recruiters reviewing thirty portfolios in an afternoon do not wait, and a broken link reads as a broken habit.

Why we care about this

We build browser-based, instantly playable games at Cinevva, which means a lot of what we make happens to be exactly what a modern portfolio needs: real work that a recruiter can open and play from a single link, no download, no install. We're paying close attention to this problem, because the people it's hitting are our people. If you got cut, your skills didn't evaporate. The market got louder, and the way you prove yourself changed.

The old question was "where did you work?" The new one is "show me something I can play, and tell me why you built it that way." That second question is harder to game and better for the people who can actually do the work. If that's you, this market is brutal, but it isn't closed. It's waiting for proof it can trust.

Sources

• GDC 2026 State of the Game Industry: layoffs, AI, and unionization
• GamesBeat: Global games workforce grew 0.6% in 4 years, North America shrank
• Wikipedia: 2022–2026 video game industry layoffs
• Outlook Respawn: Record profits, record layoffs
• Game Developer: Layoffs are slowing, but the damage is done
• TechRound: LinkedIn faces a surge in AI slop content

Related:

• The job market is transforming: from credentials to skills
• AI controversy, trust, and the post-AI economy for games
• The intuitive mind in an age of AI

By Mariana Muntean, CEO of Cinevva

Okay so we absolutely did not intend to burn an entire week on itch.io. What started as quick research turned into... well, somewhere around hour twelve we stopped counting. The whole point was finding games you can play immediately — no downloads, no installers chugging away in the background. You click, you're in. Done.

These are the ones that made the cut.

Top-Rated Interactive Experiences

Adventures With Anxiety! — Interactive Story Over 6,500 ratings with a 4.9 average. Wild that something forcing you to stare down anxiety has this many fans, right? Gets uncomfortable in the best way — the kind that sticks with you. Play it here

We Become What We Behold — Social Commentary 7,600 ratings at 4.8/5. Ten minutes to finish. Days to stop thinking about it. Play it here

Six Cats Under — Puzzle Adventure Cozy and clever. Visuals do serious heavy lifting here, which works in its favor. 4.8/5 from 6,400+ people. Play it here

Friday Night Funkin' — Rhythm Game This one's everywhere by now. 11,700+ ratings, 4.7/5. Play it here

Sort the Court! — Kingdom Sim Your only job: say yes or no. Doesn't sound like much. Then two hours vanish while you're still running a tiny kingdom. Play it here

Dragonsweeper — Puzzle Roguelike Take Minesweeper, mash it together with RPG systems. 4.9/5 — this might actually be the best thing on the whole list. Play it here

Roguelike & Strategy (Browser-Playable)

Backpack Hero — Inventory Roguelike Browser version costs nothing. Paid version adds more stuff, but the free web build stands on its own. Play it here

Vampire Survivors — Bullet Heaven Demo only — single stage, seven characters. Still enough to see why this thing consumed everyone's free time. Play it here

Dome Romantik — Mining Defense Started as a game jam thing. Became Dome Keeper. Became huge. Original prototype still holds up. Play it here

Why These Specifically?

Every single link got tested. Not a quick skim — we actually sat down and played these. They load without drama. No browser weirdness. Thousands of ratings came from folks who never touched a download button; they clicked and jumped straight in. That zero-friction path from "huh, interesting" to actually playing? Most people underestimate how much that changes things.

Browse More Web Games

Still hungry for more?

• Top rated HTML5 games on itch.io
• Best HTML5 platformers
• Games from 2024-2025

Notable Indie Games (Download Required)

Some great stuff won't run in your browser. These earn the extra step:

Slice & Dice — Dice Roguelike Runs on Windows, Mac, Android. Grab it on itch.io

Stacklands — Card Village Builder Windows and Mac. Get it on itch.io

Luck be a Landlord — Slot Machine Roguelike Sounds like a gimmick. It's not. Actual strategy underneath that slot machine surface. itch.io

Patrick's Parabox — Recursive Puzzles Expect your brain to ache. Expect to like it anyway. itch.io

Dome Keeper — Mining Defense Full release of that jam prototype we mentioned. Find it on Steam

Brotato — Arena Survivor Available on Steam

Here's something to sit with if you're making games: browser builds put nothing between players and your work. No download sitting in a queue they'll forget about. No install screen to click through. One click and they're already forming opinions about what you built. That kind of immediacy doesn't get talked about enough — but it shifts everything.

Want that for your own game? You can build one right in the browser with the Cinevva game creator, and the ones we feature land in our community Arcade.

• For game creators
• Build a web game that loads fast

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

If you want to ship a 3D game that runs in a browser in 2026, you have four mainstream choices and a few newer ones. They get lumped together as "web game engines," but they're genuinely different tools that solve different problems. Picking the wrong one costs you months. This is a current, fact-checked comparison, written by people who build a web 3D engine for a living and evaluated all of these before building our own.

We'll go through each option, what it actually is, who it's for, and where it falls down, then give you a short decision guide at the end. Where we mention version numbers, they're accurate as of June 2026.

Looking for the full field? This post focuses on the four mainstream 3D choices. For all 11 web engines ranked and compared (including 2D options like Phaser, Defold, and Construct) see our best web game engines for 2026 guide.

The quick comparison

The rest of this post explains the table.

PlayCanvas

PlayCanvas is the closest thing the web has to a Unity-style workflow. The engine is open source under the MIT license and sits at v2.19.6 as of June 5, 2026. It uses an entity-component system, you write game logic in TypeScript or JavaScript, and assets move through a server-side pipeline that produces GLB. Real commercial games run on it, and large companies use it in production, Snap being a public example.

Two things people get wrong about PlayCanvas are worth correcting. First, while the engine is MIT-licensed, the hosted visual editor that most teams actually use is a commercial product, not open source. You can use the engine freely without it, but the editor-plus-cloud workflow is the paid part. Second, PlayCanvas is WebGL2-first. It has a WebGPU path, but that path is still maturing rather than being the default renderer, so don't pick PlayCanvas today expecting production WebGPU compute shaders.

Where PlayCanvas genuinely leads is 3D Gaussian splatting. Its SuperSplat editor and viewer, which the team open-sourced, are among the best tooling anywhere for capturing and shipping splat scenes on the web, with WebGPU-based streaming for large captures. If photoreal scanned environments are your thing, that's a real reason to start here.

Choose PlayCanvas if you want a Unity-like editor and a managed asset pipeline for the browser, and you're shipping the kind of game a studio would build. Look elsewhere if you need WebGPU compute today, or you want to avoid a hosted commercial editor.

Three.js

Three.js is not a game engine. It's a rendering library, and it's the most widely used one in the space by a wide margin. It gives you a scene graph, cameras, lights, materials, geometry, loaders, and a renderer, and then it stops. There's no editor, no physics, no entity system, and no opinion about how to structure a game. You add those yourself or pull them from the ecosystem.

That trade is the whole story. You get maximum control and the largest community in web 3D, at the cost of building or assembling everything above the renderer. Its WebGPU renderer has been growing steadily and is usable today, though, as with the others, the WebGL2 path is still the mature default. Three.js is MIT-licensed.

Choose Three.js if you want full control, a minimal base, and you have the engineering to build your game systems on top. Look elsewhere if you want an editor and game systems handed to you.

Babylon.js

Babylon.js is a full engine, MIT-licensed and backed by a team at Microsoft. Unlike Three.js, it ships with the parts you'd otherwise assemble: a component model, the Havok physics engine integrated, a free web-based editor, and an asset pipeline. Its WebGPU work has moved quickly and is among the more advanced of the general-purpose engines, though it still maintains WebGL2 as the broad-compatibility path.

If your mental model is "I want a complete engine, included physics, and I'm happy working inside its conventions," Babylon is a strong default and arguably the most feature-complete free option in the space.

Choose Babylon.js if you want batteries included, built-in physics, and a free editor. Look elsewhere if you want a tiny dependency footprint or you specifically want a Unity-style hosted workflow.

Unity WebGL

Unity WebGL isn't a web engine, it's an export target. You build in the Unity desktop editor, in C#, and compile to a WebGL bundle that runs in the browser via WebAssembly. That makes it the obvious answer for one specific case: you already have a Unity game and you want a browser version of it.

For a web-first project it carries real costs. The runtime and download weight are significant, startup is slower than a native web engine, and mobile browser performance is a known pain point. Unity is proprietary and its WebGL output targets WebGL2.

Choose Unity WebGL if you have an existing Unity project to bring to the browser, or your team lives in Unity already. Look elsewhere if instant load on mid-range phones is a hard requirement, or you're starting fresh and web-first.

Where AI-native and in-world creation fits

Everything above shares one assumption: a developer builds the game at a desk, in an editor, and ships a runtime. That assumption is correct for most projects, and if it describes yours, pick from the four above.

It's worth knowing the assumption is no longer the only option, because a different category is emerging. We build Cinevva, which is a WebGPU-only world platform where games are created from inside the world. Instead of opening an editor, you're an avatar standing in the space, and you describe what you want, and an AI builder turns it into terrain, objects, and behavior while you stand there. Creation and play are the same session. Under the hood that meant going WebGPU-only with compute-shader terrain, writing a custom character solver instead of a general physics engine, and building an animation and retargeting system, which we wrote about in why we built our own WebGPU engine.

This isn't a replacement for PlayCanvas or Babylon. If you're a developer building a specific game, those are the right tools. Cinevva is for the different goal of letting people who aren't engine developers make and share playable spaces by describing them. We mention it here because "which web game engine should I use" increasingly has a fifth answer that isn't an engine at all.

The full feature matrix

The quick table up top is the headline. This is the detailed version, grouped by subsystem. A few honest notes on how to read it. "BYO" means bring your own, which is to say the engine doesn't ship it but the ecosystem or your own code can add it. This matters most for Three.js, which is a rendering library by design, so "BYO" there is a feature of the philosophy, not a gap. "Export-only" for Unity means the capability exists in the desktop editor and rides along into the WebGL build rather than being web-native. Competitor cells reflect out-of-the-box capability and well-documented behavior as of mid-2026. Cinevva cells reflect what runs in our shipped build, with "planned" marking what's designed but not yet built.

Rendering

World and terrain

Physics and character

Animation

Multiplayer and backend

Creation and authoring

Assets and distribution

The pattern in the matrix is the real story. The general-purpose engines spread their strength horizontally, they each do most things competently and leave the world, the backend, and the creation flow to you. Cinevva concentrates vertically, it does fewer things but owns the whole path from the renderer to a shared world you create from inside. Neither shape is better in the abstract. They answer different questions.

How to choose

Match the tool to the situation rather than to a feature checklist.

If you already have a Unity game, export it with Unity WebGL and accept the weight. If you're a studio that wants an editor-driven workflow for browser games, use PlayCanvas. If you want a complete free engine with physics included, use Babylon.js. If you want total control and you have the team to build on a bare renderer, use Three.js. And if your goal isn't to build one game but to let people create and play inside a shared world by describing things, that's the category we work in, and you can try Cinevva.

Whatever you pick, do the evaluation with real spikes before you commit. Each of these can carry a real game, and the cost of switching halfway is the months you didn't spend shipping.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

Every technical person who looks at Cinevva World asks the same thing within five minutes. You're a small team. Mature web 3D engines exist. Why did you write your own renderer, your own character physics, your own animation system, instead of standing on PlayCanvas or Babylon and shipping faster?

It's a fair question, and "not invented here" is the wrong answer to it. We did the homework. We ran the existing engines, read their source, and shipped spikes on top of two of them before deciding. This post is the honest version of that decision: what the off-the-shelf options are genuinely good at, the four places our needs diverged hard enough to justify building, and the situations where you should pick one of them over copying us. We documented the build itself in a long-running open-world-in-the-browser engineering series, so where a claim below has a working log behind it, I'll link to it.

The options we actually evaluated

Four things get called "web game engines," and they aren't the same kind of thing.

Three.js is a rendering library, not a game engine. It gives you a scene graph, materials, loaders, and a renderer, and then it gets out of your way. There's no editor, no physics, no entity system, no opinion about how your game is structured. That's the appeal and the cost. You build everything above the renderer yourself, but nothing fights you. It's MIT-licensed, it has the largest ecosystem in the space, and when you hit an obscure shader bug at 2am there's a forum answer waiting.

Babylon.js is a full engine with a scene graph, a physics integration (Havok), an asset pipeline, and a web editor. It's MIT-licensed, backed by a team at Microsoft, and its WebGPU work has been moving quickly. If you want batteries included and you're happy living inside the engine's structure, it's a strong default.

PlayCanvas is the closest thing to a "Unity for the web." As of this writing the engine is at v2.19.6, released June 5, 2026, and the engine itself is open source under MIT. The thing most people actually use, though, is the hosted visual editor, and that editor is a commercial product, not open source. PlayCanvas uses an entity-component system, you script in TypeScript or JavaScript, assets flow through a server-side GLB pipeline, and real commercial games have shipped on it (Snap runs production work on PlayCanvas, for one). Its renderer runs WebGL2 with a WebGPU path that is still maturing rather than the default. That last detail matters more than it sounds, and I'll come back to it.

Unity WebGL isn't a web engine at all. It's an export target. You build in the Unity desktop editor and compile to a WebGL bundle. It's the right tool when you already have a Unity game and want it in a browser, and the wrong tool when "loads instantly in a tab on a mid-range phone" is a hard requirement, because the runtime and download weight come along for the ride.

Any of these is a reasonable foundation for a normal web game. We didn't have a normal web game.

Decision one: WebGPU is our floor, not our finish line

The split that pushes us off every shelf is this. For us, WebGPU is a requirement, not a feature we'll grow into.

Our terrain isn't a static heightmap. It's a hybrid of a streamed heightmap field and marching-cubes chunks backed by a signed-distance field, so the world can have real caves and overhangs, and creators can sculpt it live. The sculpt brushes, the foliage scatter, and the terrain meshing all run as compute shaders. Take compute away and the world doesn't degrade, it doesn't run.

That's the opposite of where the general-purpose engines sit today. Their WebGPU support is designed as progressive enhancement on top of a WebGL2-first renderer, with a fallback path for browsers that lack it. PlayCanvas in particular is WebGL2-first with WebGPU still in beta. That's the correct call for them, because their job is to run the widest possible matrix of games on the widest possible matrix of devices. Our job is narrower and deeper, so we made the opposite call: we went WebGPU-only at spike 13 and never looked back. Browsers without WebGPU aren't downgraded, they're unsupported, and we track that as a reach number instead of pretending a WebGL2 fallback is one config flag away. It isn't. It would be a partial rewrite of our terrain and foliage stages.

Building on a WebGL2-first engine would have meant either fighting its fallback assumptions on every compute feature, or maintaining two rendering paths forever. Owning the renderer let us treat compute as the baseline.

Decision two: a character solver, not a physics engine

The textbook move is to drop in a physics engine. We tried it. An early spike validated Rapier running in a worker, and it felt fine.

We wrote our own anyway, and there's no Rapier, Cannon, or Ammo anywhere in the shipped build. The reason is scope. We don't need rigid bodies, joints, ragdolls, or a constraint solver. We need one capsule to move correctly against terrain, and we need walking, sliding, gliding, climbing, and swimming to agree on a single shared answer to "am I grounded, on what surface, at what angle." A general physics engine makes that harder, not easier, because those modes end up fighting its internal springs and dampers.

So our character controller is a pluggable multi-channel state machine. Each mode is a small unit that says whether it wants control this frame and, if it wins, writes velocity and facing. They arbitrate by priority across three channels, resource then stance then locomotion, and they all read the same terrain query. Collision is a capsule probe against the heightmap or the signed-distance field depending on the chunk.

The detail I'm proudest of is unglamorous. Ground detection scans every surface in the vertical column beneath your feet and picks the highest one at or below the capsule, instead of trusting the SDF gradient. On the edge of an overhang the nearest surface sideways is the cliff face, so a gradient-based normal flickers between "floor" and "wall" and you get phantom sliding. The column query makes standing on a ledge boring, which is exactly what you want. An off-the-shelf heightfield collider would not have given us that for free, because it can't see our terrain in the first place. The terrain lives on the GPU in our format. No external engine can collide against it without us copying the whole field into its collider format on every edit.

Decision three: animation that travels across rigs

Avatars use the Synty POLYGON rig, and our motion clips come from a large open animation library. Because the rig and the clips share bone names, the common case needs no retargeting at runtime, the tracks just bind by name. We wrote up the full character pipeline in universal characters.

The interesting work is the case where they don't match. We built a retargeting pass that maps one skeleton onto another, and getting it right meant solving three specific problems. You align bind poses first, because an A-pose against a T-pose silently adds about thirty degrees per joint. You scale root motion and stride with two separate ratios, hip-to-floor for the vertical and overall proportion for the horizontal. And you test retargeted clips against their source at a fixed sample rate, so regressions show up before a player does. That pipeline is what lets us add new animation sources, and eventually creator-supplied characters, without hand-fixing every clip.

On top of that sits an animation state machine that picks the right clip family each frame from the motion state: jump variant by speed, landing severity by impact, slope direction from the dot of velocity against the terrain gradient, foot-phase-correct stops so you don't moonwalk to a halt, and a hundred-millisecond debounce so bumping a wall doesn't strobe you between walk and fall. None of this is exotic, but it's the kind of thing you only get by owning the layer.

Decision four: the part no engine ships

The other three decisions are about how the world runs. This one is about what the product is, and it's why the comparison to PlayCanvas is ultimately a category error.

PlayCanvas, Babylon, Unity, and a hand-rolled Three.js app all assume the same shape: you build your game at a desk, in a 2D editor, looking at the world from outside, and then you hit play and ship a separate runtime. Even their in-engine editing is you-at-a-workstation manipulating a scene you're looking at.

Cinevva World inverts that. You create from inside the world, as an avatar standing in the same space your players will stand in, by describing what you want and watching it appear. Creation and play are one continuous session, not a build step bridged to a runtime. The closest reference points are Roblox, Rec Room, and Horizon Worlds, not web 3D engines, and even those keep most creation at a desk. The thing that makes it tractable without a mouse-driven editor is the AI builder, which turns "put a lantern-lit dock here" into geometry and placement.

You can't bolt that onto a general-purpose engine, because it isn't a rendering feature. It's the premise of the whole stack, from how terrain is editable at runtime to how the network treats every object as something a person standing nearby just made.

When you should not do what we did

Here's the part the "we built our own engine" genre usually skips. If you want to ship a browser game this quarter, do not copy us. Use PlayCanvas if you want a Unity-style editor and a managed pipeline. Use Babylon if you want a full engine with physics included and you're happy inside its structure. Use Three.js if you want maximum control and minimum opinion and you have the team to build above it. Port from Unity if you already have a Unity game.

Writing your own renderer, physics, and animation is only the right call when your product's premise is incompatible with the shelf, when the thing you're building isn't a game on an engine but a place that happens to be made of one. That was true for us. It probably isn't true for you, and that's fine. The point of doing the evaluation honestly is knowing which case you're in before you write the first line.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

We can generate worlds now, and I don't mean in a demo reel. The picture above is our editor. Someone typed "build a second floor" into a chat box and watched the AI lay the floor deck, raise the front, side, and back walls, and offer to keep going with stairs and a roof. Not props, not textures, whole structures, dropped into a world other people can walk into. Our pipeline already makes the parts too: 3D models, music, sound, materials.

So we're close to opening Cinevva World to the public. And before we do, I went and read the obituaries.

Because here's the uncomfortable truth about what we're building. For fifteen years, very smart, very well-funded teams have tried to make shared creative worlds work. A few became some of the largest things humanity has ever built. Most are dead. The gap between the two outcomes is not talent and it is not money, because some of the dead had more of both than we will ever have. The gap is a small number of decisions that almost nobody gets right on the first try. This is what I found.

The graveyard

Start with the failures, because they're more honest than the success stories. Winners rewrite their history into a clean narrative. Losers leak memos.

Meta Horizon Worlds: the most expensive empty room ever built

Meta spent tens of billions on its metaverse bet. Reality Labs posted a $6.02 billion operating loss in a single quarter reported in early 2026, and it had been bleeding multiple billions per quarter for years. The flagship was Horizon Worlds. Here is what that money bought.

A leaked internal memo, reported by Fortune and Ryan Schultz, revealed that only about 9 percent of the worlds creators built were ever visited by 50 or more people. The vast majority got zero visits beyond their own maker. One memo summed up the engagement problem in a sentence that should be tattooed on every founder in this space: "an empty world is a sad world." Researchers wanting to survey active users could find only 514 of them, because the player base was that small.

The retention numbers were worse. Leaked data showed only about 1 in 10 users returned after their first month. Meta quietly cut its own 2022 target from 500,000 monthly users down to 200,000, and even then the platform had fewer concurrent users than VRChat and fewer than Second Life, a game from 2003. Internal dogfooding dashboards showed that Meta's own employees weren't using it, which pushed management to start holding managers accountable for weekly logins. A VP put the team into a "quality lockdown" for the rest of the year and admitted, in writing, that they were working on a product that had not found product-market fit.

In March 2026, Meta announced it was killing VR support entirely and turning Horizon Worlds into an almost-exclusively mobile app, an entry point for people without headsets, functioning, in their own framing, like Roblox. The most expensive metaverse ever built ended its life trying to become the thing it should have been on day one.

The lesson isn't "VR was too early," though it was. The lesson is that no amount of capital fills an empty world. Content density is not something you can buy with a marketing budget. If the worlds are empty, people leave, and when people leave, the worlds stay empty. That loop ate Meta alive.

Decentraland and The Sandbox: the billion-dollar ghost towns

In October 2022, a single data point set the crypto world on fire. DappRadar reported that Decentraland had 38 daily active users. The Sandbox had 522. Each of these projects carried a market capitalization around $1.3 billion at the time.

Now, the projects pushed back, and the nuance actually matters more than the dunk. The 38 figure counted only unique wallets making on-chain transactions in a day, what DappRadar calls "payers," not people who logged in and walked around without touching the blockchain. Decentraland countered that it had 56,697 monthly logged-in users and roughly 8,000 daily, by other estimates. The Sandbox claimed 39,000 daily during an alpha season with a day-14 retention of 40 percent.

But sit with the gap for a second, because it's the most important number in this whole essay. Even taking the charitable figures, you have billion-dollar valuations sitting on top of, at best, a few thousand daily users. For comparison, the research turned up that non-blockchain Roblox had 52 million daily active users but only 11.3 million monthly paying users in the same period. Most people in free virtual worlds transact rarely or never. That cuts both ways. It means the 38-DAU dunk was unfair, and it means the billion-dollar valuation was a fantasy. Both things measured the wrong number. The valuation measured token speculation. The dunk measured wallet transactions. Neither measured whether anyone was having fun.

That is the vanity-metric trap in its purest form. Registered accounts, token market cap, total addressable market, press impressions: none of them tell you if your world is alive. The only numbers that do are how many people come back, and whether the people who make things keep making things.

Dreams: the most beautiful tool nobody could stay in

Media Molecule, the studio behind LittleBigPlanet, spent the better part of a decade building Dreams, a creation tool so deep that people made playable games, animated short films, and music albums inside it. Critics adored it. And in September 2023, the studio ended live service, saying plainly that they could not find a sustainable business model.

The postmortem is a checklist of self-inflicted wounds, and I say that with enormous respect, because we could make every one of them. Dreams never let creators monetize their work. The promised in-game store never shipped. There were no cosmetics, no battle pass, nothing. Serious creators, the kind who turn a tool into a platform, had no reason to invest years when there was no upside. It launched PS4-only, with no PC version and no native PS5 build at launch, which capped its possible audience hard. And the co-founder Mark Healey later said his biggest regret was not focusing on multiplayer, and that the team came to understand their creation worked better as a game than as a creative tool.

Read that last part again. The most talented UGC studio on earth concluded, after the fact, that the thing should have been a game first and a tool second. That is the single most important sentence in this entire study, and we'll come back to it.

The rest of the cemetery

The pattern repeats with grim consistency.

Crayta, a collaborative UGC creation platform, shut down in March 2023 and users lost everything they'd made. Its developer was acquired by Meta in 2021 and the platform still got killed. The proximate cause: it launched on Google Stadia, and when Stadia died, Crayta died with it. Platform dependency is a loaded gun pointed at your own head.

Project Spark, Microsoft's UGC game-maker, shut down years earlier on the same arc: a powerful tool, not enough people who stayed. Sansar, Linden Lab's VR successor to Second Life, was sold off after failing to find an audience. High Fidelity, the second metaverse company from Second Life's own founder Philip Rosedale, pivoted away from virtual worlds entirely.

And in a signal you can't ignore because it's happening right now, Rec Room announced it is shutting down effective June 1, 2026, stating it never reached sustained profitability.

Founders of metaverse companies, building metaverses, could not stay in their own metaverses. That should terrify anyone who thinks the hard part is the rendering.

The survivors, and what actually saved them

Now the living. The instructive thing is that none of them won the way you'd expect, and several won despite breaking rules the failures followed.

Roblox: the twelve-year overnight success

Everyone cites Roblox as the model. Almost nobody copies what actually happened, because what actually happened was twelve years of looking like a failure.

Roblox's 2006 beta drew around 100 tech enthusiasts with a peak concurrency of 30 to 40 people. It then ground forward for over a decade. It went from 9 million users in early 2016 to 90 million in 2019 to 214 million by 2023. Founder David Baszucki refused to pivot off the user-generated-content vision even when Minecraft exploded past him in 2009. He treated it as a deliberate slow bake, and the one move that mattered was the decision to let the community build all the games rather than building them in-house. That removed content cost and turned every creator into a growth engine.

But here is the part the cargo-culters miss, and it's why I keep a second source open. Matthew Ball's 2024 teardown shows Roblox operating at a brutal loss even at massive scale, a roughly negative-38-percent operating margin, with only 6 percent of users buying its currency in a given month and revenue per user a fraction of console platforms. Roblox is the biggest game in the world and it still struggles to make money. The flywheel is real and the economics are hard. Anyone who tells you a creator platform is a license to print money is selling you something.

The deeper lesson, though, is hiding in plain sight in those user numbers. The overwhelming majority of Roblox's hundreds of millions of users never build anything. They show up to play a catalog of tens of millions of games other people made. That catalog took a decade and a developer-payout economy to grow. Roblox is not a building tool that people happen to play. It is a place to play that a small fraction of people happen to build. That ordering is everything.

Minecraft: the world that could not be empty

Minecraft never had the empty-world problem, and understanding why is the whole game.

Minecraft shipped as a survival game with procedural generation. The world builds itself, infinitely, and on minute one you are not staring at a blank canvas wondering what to do. Night is falling and something is going to kill you, so you dig. The game is fun for one person with zero other users and zero user-generated content, forever, because the procedural generator is an inexhaustible content machine. The mods, the servers, the custom maps, the entire creative ecosystem, all of that grew on top of a game that already sold itself. Creative mode came after millions were already hooked on survival. Word of mouth and YouTube did the rest.

Minecraft solved cold-start by never having one. That is the cheat code, and we'll steal it.

Browser games: distribution as the entire moat

Then there's the genre that's closest to our actual delivery mechanism, the no-download browser game.

Agar.io reached roughly 5 million daily players within weeks of its 2015 launch. Slither.io racked up 68 million mobile downloads and 67 million browser plays. The research is blunt about why: "the competitive moat for the .io genre is distribution itself, not the game mechanic." You click a link and you are playing. No install, no account, no app store. Agar.io's onboarding was one click: type a name, hit play, you're in. It spread through chat apps the way video spreads on TikTok.

But there's a knife in this gift, and it cuts our way too. No download means no commitment. The same frictionlessness that gets someone in gets them out, because closing a tab costs nothing. Browser virality is real and it is also shallow by default. The .io games survived it by being instantly, obviously fun in the first ten seconds. The browser worlds that died were frictionless to enter and gave you no reason to stay once you arrived.

Among Us, Figma, Townscaper, VRChat: four more ways to win

Four quick ones, because each isolates a different lever.

Among Us launched in 2018 and was a commercial nothing for two years. The developers nearly abandoned it. Then in September 2020 a ladder of progressively bigger streamers discovered it, culminating in a multi-hour Sodapoppin stream, and it became a global phenomenon. The early oxygen came from an itch.io front-page feature and a Korean audience that became half its sales. Lesson: the breakout can come years after launch, from a channel you didn't plan, if you survive long enough to be discovered.

Figma stayed in stealth for about three years, launched free, and waited two more years before charging. Its activation moment was multiplayer: the instant a designer felt someone else editing the same file. And here is the part that matters. Figma's free tier originally limited you to 2 collaborators, which strangled the exact magic moment that sold the product, and they fixed it by making collaborators unlimited so people could actually feel the thing. They seeded the community by targeting design influencers on Twitter directly. Lesson: find your aha moment, then remove every obstacle between a new user and it.

Townscaper was a tiny creative toy that became a hit on the strength of screenshots. Its developer watched his Twitter following jump from around 20,000 to 90,000 just by posting clips during development, and read that as the early signal it would do well. Lesson: if your thing is beautiful and people share it unprompted before you've even launched, that is the realest validation there is.

And VRChat, in the same months that Meta's billions and Rec Room both folded, hit a record of nearly 160,000 concurrent users. It is community-driven, creator-driven, and not remotely as well funded as the things that died around it. VRChat credits its survival to community loyalty and creativity over capital. Lesson, stated by the survivor itself: engaged creator passion outlasts money.

What actually separates the living from the dead

Lay the stories side by side and the pattern is not subtle.

The thing that kills creative worlds is the empty room. Horizon Worlds, Decentraland, Dreams, Crayta, Project Spark, Sansar, all died the same death: not enough people, not enough content, not enough reason to come back, in a loop that feeds on itself. The cold-start problem is the boss fight. Everything else is a tutorial level.

The thing that saves them is having a reason to exist before the crowd shows up. Minecraft had procedural survival. Roblox had a decade of patiently seeded games. The .io games had ten-second fun. Every survivor was worth your time with an empty catalog. Every casualty was a beautiful container waiting for other people to make it worth visiting. This is the Dreams confession made general: build a game first and a platform second. The platform is the second act. You earn it by first being something people use for its own sake.

The metrics that actually predict survival are not the ones in the press release. The research is consistent here. The defining signal of product-market fit is that your retention curve flattens: some cohort of people keeps coming back forever. A curve that declines to zero means no fit, no matter how big the top of the funnel. Rough industry benchmarks are 40 percent day-1, 20 percent day-7, 10 percent day-30 retention, with day-30 being the one that predicts long-term health. And for anything with a creator side, the supply side is where you die: about 67 percent of failed marketplaces collapse on supply, not demand. Creator retention is the vital sign. Registered accounts and valuations are the vanity.

A few more that fall out of the stories. Monetize your creators or lose them, because Dreams proved that talented people will not invest years for no upside. Multiplayer is usually the point, not a feature, per Media Molecule's own regret. Never build your house on a platform that can evict you, per Crayta. And no-download is a double-edged sword: it is the best acquisition channel in existence and the weakest commitment device, so the burden falls entirely on the first sixty seconds being good.

The trap underneath all of it

There's one more layer, and it's the one specific to our moment, because we have a tool the dead never had. We can generate worlds with AI. Which raises a paradox I've gone back and forth on for weeks.

If it's AI, shouldn't every world be unique, generated fresh for each person, tuned to them? But if each person's world is unique, how does anyone ever bump into anyone else, given that a shared moment requires a shared place? And if the world has to be shared anyway, then why use AI at all, instead of handcrafting one beautiful place like a real studio?

Each of those pulls, followed to its end, lands on something that doesn't work. A world generated just for you is a world with nobody in it. Google's Genie can spin up a playable environment from a sentence and it vanishes a minute later, single-player, no memory, no neighbors. That's the lonely dead end. But handcrafting one fixed world is also a dead end: it's a hundred-person, multi-year job to fill two square kilometers by hand, and when you're done it's frozen, the same on your hundredth visit as your first, unable to grow as people arrive.

The way out is to stop treating "the world" as one thing. It's three layers, and uniqueness and sharedness can live in different ones without fighting. The ground everyone stands on is one shared world, curated to a high bar, the meeting place. What you bring to it, your AI-generated assets, the building you made, is wildly unique, and you deposit it into the shared world so your uniqueness becomes everyone else's discovery. And your path through it, the quests you get, what it points you toward, is personalized for free, because a path is not a place. The false choice was "a personalized world," which kills multiplayer, versus "a personalized path through a shared world," which deepens it. We want the second.

So AI's job was never to hand each person a private world. Its job is to make one shared world feel infinite, alive, and personal to move through. The uniqueness comes from everything that accretes in it over time, every creator's one-of-a-kind contribution. Every Minecraft server is unique. Everyone on a given server shares it. That is not a contradiction. That is the whole trick, and the screenshot at the top of this post, the AI building a house that stays put in a world other people can walk into, is that trick made real.

How we're launching Cinevva World

So here is what all of this turns into for us. Not a marketing plan. Five bets, placed deliberately against the five things that killed everyone in the first half of this piece. And I'll grade each one by how much the evidence actually backs it, because a plan you can't grade is just a wish with good lighting.

Bet one, the one I would stake the company on: we launch a game, not a platform. This is not a preference, it is the most consistent finding in the entire study. Minecraft, Roblox, and Fortnite all led with something fun to do and grew the creator layer on top of it. Media Molecule, the most gifted creation studio alive, concluded after the fact that Dreams should have been a game first. So the first thing a new person does in Cinevva World will not be staring at an empty plot. It will be a loop with a goal, a reason to be there on a Tuesday when almost no one else is online. Most people who show up will play and never build, and that is the design, not a failure. It is Roblox's actual shape: hundreds of millions who play, sitting on a thin layer who create. The flywheel is the second act, and we have to earn it. I'm sure of this one because the graveyard already ran the experiment.

Bet two, the one that is honestly a wager: AI lets us manufacture the supply everyone else died waiting for. I want to be precise about why this is a bet and not a guarantee, because no platform in this study was ever bootstrapped with generative AI. I have a mechanism, not a proof. The mechanism: roughly two thirds of two-sided platforms die on the supply side, not the demand side. The classic fix is to fake supply until it's real, the way DoorDash drove the food itself, Reddit's team posted under fake handles, and Roblox's founders hand-built the early games for years. We can do that with generation, at a cost and speed none of them had. But here is the part that keeps me honest, and it is the Decentraland tombstone: Decentraland was full of generated stuff and drew about thirty people a day, because pretty is not the same as worth-your-time. So I am not betting that AI makes the world fun. It can't. I am betting that AI removes the asset bottleneck so that every hour of our scarce human effort goes into the one thing that actually retains people, the loop. AI builds the hill cheaply. We hand-build the reason to climb it. And we cap the synthetic seed at roughly 30 percent, converting it to real creator content inside about 60 days, because fake supply that never turns real breaks trust the instant anyone notices.

Bet three: we publish our own kill-criteria. This is the difference between a grounded plan and a hopeful one. The metric that predicted survival in every single case was whether the retention curve flattens, whether some cohort keeps coming back instead of decaying to zero. So that is the test we hold ourselves to, out loud. If alpha day-7 retention does not flatten, if the players who never build do not return, if the AI-seeded content gets walked past and ignored, the thesis is wrong, and we change it or we stop. We will track players and creators as two separate funnels with two separate aha moments, because the data is clear they are not the same person. And we will not pretend money does the early work. At fifty users, or even a thousand, tips and marketplace earnings round to zero, so they retain no one yet. Early retention comes from the loop or it does not come at all. Dreams is the receipt for getting that backwards.

Bet four: we start narrow on purpose. The research on networked products is unanimous. You do not launch to a market, you launch to an "atomic network," the smallest group dense enough to be alive on its own. Facebook started at one school. Ours already exists: the Cinevva creators who have generated 3D assets, music, and sound, and who already have inventory to place. Fifty of them in one world at the same hour, with a goal and a frontier, is a denser and more alive thing than fifty thousand scattered signups will ever be. The evidence backs this one hard.

Bet five, the softest, and I'll say so: we tell the truth about the emptiness instead of hiding it. A polished, quiet world reads as dead, and the failures all tried to cover that with ambient effects. We will try the opposite. This is the least proven move of the five, closer to a hunch than a finding. The first people in are not visiting an unfinished product. They are the founding citizens of a place that is empty because they're early, and what they build will still be standing when the next thousand arrive.

That is the plan, graded honestly. Four bets the graveyard strongly supports, and one real wager on a tool none of the dead had, fenced in by the exact discipline they lacked. We can generate the hill. We cannot generate the feeling of being first up it, or the stranger who waves from the top. The job is to make that wave possible, prove it on the retention curve, and stop fooling ourselves the moment the curve says no.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 29 gave us one controller that drives any body. The body moves correctly now. It walks, slides, swims, glides, climbs into caves, and ducks under overhangs. The problem is what's watching it. For twenty-nine parts the camera was a stock orbit rig that followed the player and did exactly one clever thing to avoid embarrassment, it refused to tilt below the horizon so it couldn't slide under flat ground. That clamp is the tell. It exists because the camera had no idea where the world's geometry actually was, so the only defence against clipping was to forbid the angles where clipping was most likely. Walk up to a hill and the camera sat inside the hill. Step into one of the marching-cubes caves from Part 7 and you were looking at the inside of a rock. Build a house with the authoring tools from Part 16 and stand in a room, and the camera floated outside the wall looking at siding. This part gives the camera the same respect for geometry the body already has.

The shape of the problem, and the shape of the fix

A third-person camera has one job that's hard and a dozen that are easy. The easy ones are following, smoothing, and orbit input, and we already had those. The hard one is the academic literature calls it a visibility constraint, and the survey everyone cites, Christie and Olivier's Camera Control in Computer Graphics, frames the whole field around it: keep the subject framed and unoccluded while respecting the world. At runtime that reduces to a deceptively simple question asked every frame. The player is the pivot. The user has rotated and zoomed to a desired camera position some distance behind them. How far back can the camera actually sit along that line before it pokes into something solid? Answer that honestly and the camera tucks itself in front of the hill, slides down the boom as you back into a corner, and stops at the cave ceiling instead of punching through it.

The pattern that answers it is old and proven. Unreal calls it a spring arm, Godot ships a SpringArm3D node, and Unity's Cinemachine splits it across a third-person follow rig and a deoccluder extension. The idea is always the same. Hang the camera off the end of a boom anchored at the pivot. Hold it at the desired length when the path is clear, retract it toward the pivot when something's in the way, and spring it back out when the way clears. Mark Haigh-Hutchinson's Real-Time Cameras, written by the camera lead on Metroid Prime, spends whole chapters on the failure modes that turn a naive version of this into something that makes players sick. We took the pattern and built our own, small enough to read in one sitting, in public/world/src/camera-rig.mjs.

A boom that owns only its length

The design rule that kept the rig small is a borrow from the controller work in Part 29: own one thing, completely, and refuse the rest. The rig owns the length of the boom and nothing else. Yaw, pitch, damping of the orbit, touch and wheel gestures, all of that stays with OrbitControls, which already solves it well and which we have no interest in rewriting. So the rig is not a camera controller. It's a post-process that runs after the orbit math and corrects exactly one number, the distance from pivot to camera.

That decision sounds tidy and it almost broke immediately, because of how OrbitControls thinks. At the top of every update it reads the camera's current position and derives its orbit radius from it. That's normally invisible. But the instant our rig shortens the camera to dodge a wall, the next frame OrbitControls reads that shortened position, concludes the user must have zoomed in, and bakes the shortening into the user's desired zoom. A few frames of that and the camera has collapsed onto the player's head and won't come back out. The fix is two calls that bracket the orbit update and it's the whole integration. Before OrbitControls runs, beforeControls() restores the camera to last frame's full, un-shortened distance, so the orbit math always reads the user's true zoom. After OrbitControls runs, afterControls(dt) reads that freshly orbited desired position, resolves the collision, damps the length, and writes the camera where it should actually render. The user's intent and the collision correction never touch each other, and the dolly stays exactly as responsive as it was before the rig existed. The headless test we wrote for the rig pins this precisely: drive the boom into a wall for sixty frames, clear the wall, and the length springs back to the user's full zoom of ten metres rather than sticking at the collision distance.

One contract, any collider

The rig never asks what the world is made of. A collider is just an object with a probe method, and the rig hands it a ray, a maximum distance, and the camera's probe radius, and gets back one number, the furthest the camera may travel before that collider blocks it. The rig queries every registered collider and takes the nearest hit. That's the entire contract, and it's the same move the character controller made when it turned locomotion into pluggable behaviours. Terrain plugs in, props plug in, building shells plug in, each behind the same probe, and the rig stays ignorant of all of them. Adding a new kind of obstacle is adding a collider to a list, not editing the camera.

One detail in the contract earns its keep, and it's the probe radius. We don't cast a thin ray from pivot to camera, we cast a sphere big enough to contain the camera's near plane. A single ray stops the camera centre at the wall, but the near plane has width, so its corners would already be buried in the wall before the centre ray ever reported a hit. Sweeping a small sphere instead of a ray is what every shipping implementation does, Unreal exposes it as the probe size, and it's the difference between a camera that rests cleanly against a surface and one that lets you see through it at the edges of the screen.

We don't guess that radius, we derive it. The furthest point of the near plane from the camera is one of its corners, and the distance to it falls straight out of the projection. With near plane $n$ and vertical field of view $\theta$, the half-height is $h=n\tan (\theta /2)$, the half-width is $w=h\cdot \text{aspect}$, and the corner sits at

The probe radius is that corner distance times a small safety margin, with a fixed floor so it never drops below a sensible minimum on a very narrow frustum. Whenever the field of view, aspect ratio, or near plane changes, the radius is recomputed, so a window resize or a zoom that touches the projection can't quietly leave the probe too small to cover the corners it's meant to protect.

The collider that knows about caves

The terrain collider is where this gets interesting, because terrain in our engine isn't a heightmap. Since Part 7 it's been a signed distance field, a function that returns how far any point in space is from the nearest solid surface and whether it's inside or outside the rock. Positive is air, negative is rock, and that single fact is why our camera can do something a heightmap camera structurally cannot. A heightmap knows the ground height at an x and z. It has no concept of a ceiling, because there's only ever one surface above any point. So a heightmap camera can stop you walking into a hill, but it has no idea an overhang lip or a cave roof is hanging over the pivot, and it sails right through both. A distance field knows about every surface in three dimensions, so the same probe that stops the camera against a hillside stops it against a cave ceiling without a single special case.

Walking the probe along the field is a technique with a name and a paper behind it. John Hart's Sphere Tracing, from 1996, is the standard way to march a ray against a distance field, and the trick is that the field doesn't just tell you whether you've hit something, it tells you a safe distance you can advance without hitting anything. So instead of creeping along in tiny fixed steps, you sample the field, step forward by the slack it reports, and repeat, taking long strides through open air and short careful ones as you close on a surface.

There's a catch our terrain forces on us, though. A true distance field reports the real Euclidean distance to the nearest surface, and a full stride by that slack is always safe. But where the terrain is still a heightmap rather than carved voxels, the field we can cheaply sample isn't true distance, it's vertical clearance, the gap straight down to the ground. On a slope that number over-reports how far the camera can actually move, because the nearest rock is off to the side, not directly below. The honest distance is smaller by a factor that grows with the gradient, $\sqrt{1+\Vert \mathrm{\nabla }h{\Vert }^2}$, so a stride sized for the reported slack overshoots and can hop clean over a ridge. The fix is under-relaxation, advancing by only a fraction of the reported slack rather than all of it, which stays safe up to roughly a sixty-degree slope and costs nothing on the true-distance voxel regions beyond a few extra samples. We pair that with a stride floor, so a cave wall a cell or two thick is never stepped clean over, and a tighter ceiling that keeps the march cheap. When the sphere finally touches the surface a short bisection tightens the contact point, and the camera backs off by its own radius and rests there.

Written out, the boom is a ray $\mathbf{r}(t)=\mathbf{p}+t\mathbf{d}$ from the pivot $\mathbf{p}$ along the unit direction $\mathbf{d}$, and the march advances by an under-relaxed fraction of the field's slack to contact, clamped at both ends:

Here $\mathrm{\Phi }$ is the signed distance, positive in air and negative in rock, $r$ is the probe radius, $\lambda \in (0,1]$ is the under-relaxation factor that keeps the over-reporting heightmap field from hopping a slope, and $s_{min},s_{max}$ are the step clamps that keep a thin wall from being skipped and the march from running long. Contact is the first $t$ where $\mathrm{\Phi }(\mathbf{r}(t))\le r$, meaning the sphere surface has reached the rock, and the camera holds at that arc length less its radius.

The collider carries one more method as a safety net, depenetration. Collision should keep the camera out of solid in the first place, but a few situations sneak past it, a pivot straddling a wall thin enough that the boom starts inside it, a cave freshly carved by the terrain tools while the camera sat in the rock that's now gone, a building piece dropped around the camera. For those the collider checks whether the camera ended the frame inside solid, where $\mathrm{\Phi }(\mathbf{c})<r$, and if it did, reads the field's gradient, which points straight toward open air because $\mathrm{\Phi }$ grows as you leave the rock, and steps the camera out along it:

A handful of those iterations converges on the $r$-isosurface, and it's the thing that means a sculpting tool can dig the ground out from under the camera and the view recovers on the next frame instead of going black.

Snapping in, easing out, and not flinching at fence posts

A boom that simply jumps to the collision distance every frame is worse than no boom at all, because the world is full of thin things the camera passes behind for a single frame, a fence post, a lamp, a tree trunk, and a camera that lunges to dodge each one and lunges back is nauseating. Haigh-Hutchinson's book and Itay Keren's much-loved talk on camera motion both land on the same intuition, which is that the camera should react to threats and danger faster than it relaxes from them. So the damping is deliberately asymmetric. When an occluder appears and the boom needs to shorten, it snaps in almost instantly, because a frame of clipping is ugly and the player forgives a fast tuck. When the occluder clears and the boom wants to lengthen, it eases out slowly, and only after a short dwell timer of continuous clearance has elapsed. That dwell is the hysteresis that kills the flinch. Whip the camera past a thin post and the post never clears long enough to trigger the slow extension, so the camera glides past it as if it weren't there, which is exactly what your eye wants. Cinemachine exposes the same idea as separate damping-into and damping-out-of collision values, and the asymmetry is the part that makes it feel like a camera operator rather than a spring.

In code it's one line of exponential smoothing with the rate switched on the sign of the change. If $\ell$ is the current boom length, $a$ the length collision allows this frame, and $\mathrm{\Delta }t$ the frame time, then

and the ease-out branch only runs once the clearance has held for the dwell time $\tau$. The $1-e^{-k\mathrm{\Delta }t}$ form matters beyond looking tidy. It fixes the response time constant at $1/k$ regardless of frame rate, so the camera feels identical at 30 and 144 frames per second, where the naive constant-blend $\ell \leftarrow \ell +\alpha (a-\ell )$ would snap faster on a fast machine and mush on a slow one.

The last behaviour is for the tight interiors that started this whole part. When the boom collapses short enough that the camera is right on top of the player, we hide the player's own avatar and let the view sit near first person. This is what Breath of the Wild does in a cramped shrine and what most third-person games fall back to in a corner, because the alternative, a camera jammed against a wall staring at the back of a head, is useless. The rig exposes a single flag for it, and the world loop reads the flag and toggles the local avatar's visibility. Below a metre of boom you're effectively in first person, the walls are honoured, and the moment you back into a room with space the avatar fades back in and the boom extends.

What plugs in next

The terrain collider ships today and it's the hard half, because terrain is everywhere and a distance field is the awkward thing to probe. The props and the building shells from the authoring spikes are the easy half, and the contract is already waiting for them. A second collider, a raycast collider, casts from the pivot toward the camera against a list of meshes and reports the nearest hit the same way the terrain collider does. The cheap version casts a single ray, which is fine until prop counts climb, and the upgrade is to swap the ray for a swept sphere using three-mesh-bvh, Garrett Johnson's library that wraps a mesh in a bounding-volume hierarchy so spatial queries run in log time instead of brute force. Either way the rig doesn't change. It queries a longer list of colliders and takes the nearest hit, which is the entire point of having built the contract first and the colliders second.

Technology referenced in this chapter

A boom that owns one number. The camera rig is a post-process over OrbitControls, not a replacement for it. It owns the length of the boom and leaves yaw, pitch, zoom, and gesture handling with the orbit controller we already trusted. The integration is two bracketing calls: beforeControls() restores the previous frame's full distance so the orbit math reads the user's true zoom rather than mistaking a collision shortening for a dolly-in, and afterControls(dt) resolves the collision and writes the rendered position. Without that pair the camera collapses onto the player over a few frames.

A pluggable collider contract. A collider is any object with a probe that answers "how far can the camera travel from the pivot along this ray before you block it." The rig queries every collider and takes the nearest hit, ignorant of whether the obstacle is terrain, a prop, or a wall, which is the same own-one-thing discipline the pluggable character controller used for locomotion. The probe is a swept sphere sized to contain the near plane, not a thin ray, so the frustum corners never clip a surface the centre ray would miss. Its radius is derived from the projection, the distance to a near-plane corner $\sqrt{n^2+w^2+h^2}$ times a safety margin, and recomputed whenever the field of view, aspect, or near plane changes.

A signed-distance terrain probe that honours overhangs and caves. Because terrain is a signed distance field rather than a heightmap, the same probe that stops the camera against a hillside stops it against a cave ceiling, the case a heightmap raycast structurally cannot see. The march is Hart-style sphere tracing, stepping by an under-relaxed fraction of the slack the field reports and clamped at both ends, because the heightmap regions report vertical clearance rather than true distance and over-report how far the camera can move on a slope, so a full stride would hop a ridge. A gradient-driven depenetration pass is the safety net that recovers the view when the ground is sculpted out from under the camera.

Asymmetric damping with a dwell timer. The boom snaps in fast when an occluder appears and eases out slowly once it clears, and only after a short window of continuous clearance, so whipping past a fence post never makes the camera lunge. Below a collapse threshold the rig flags near-first-person and the world loop hides the local avatar, the standard fallback for tight interiors instead of a camera buried in a wall.

References

The framing of camera control as a visibility constraint comes from Marc Christie and Patrick Olivier, Camera Control in Computer Graphics (Computer Graphics Forum, 2008). The distance-field march is John C. Hart, Sphere Tracing: A Geometric Method for the Antialiased Ray Tracing of Implicit Surfaces (The Visual Computer, 1996). The spring-arm pattern and its probe-sphere collision are documented in Epic's Spring Arm Component and Unity's Cinemachine Deoccluder and Third Person Follow. The motion and damping intuition is from Mark Haigh-Hutchinson, Real-Time Cameras (Morgan Kaufmann, 2009), and Itay Keren, Scroll Back: The Theory and Practice of Cameras in Side-Scrollers (GDC 2015). The mesh-collider upgrade path is Garrett Johnson's three-mesh-bvh.

Part 30 of 30. Previous: Part 29 - One controller, any body Series guide: /blog/2026-02-25-open-world-browser-series-guide

This page exists to verify that LaTeX math renders in our markdown articles. Math support is provided by markdown-it-mathjax3, enabled with markdown: { math: true } in the VitePress config.

Inline math

Write inline formulas by wrapping them in single dollar signs. Einstein's relation $E=m{c}^2$ sits in the flow of a sentence, as does the golden ratio $\phi =\frac{1+\sqrt{5}}{2}$ and a quick sum like $\sum _{i=1}^{n}i=\frac{n(n+1)}{2}$.

Block math

Wrap a display equation in double dollar signs on their own lines.

The quadratic formula:

Matrices and aligned equations

A 2x2 matrix:

Multi-line alignment with aligned:

Greek, subscripts, and operators

Gradient descent step: ${\theta }_{t+1}={\theta }_t-\eta {\mathrm{\nabla }}_{\theta }J(\theta )$.

A softmax: $\sigma (z{)}_i={\displaystyle \frac{e^{z_i}}{\sum _{j=1}^K{e}^{z_j}}}$.

Escaping a literal dollar sign

To show a real dollar amount without triggering math, escape it: it costs $5 to $10. Only unescaped $ pairs are treated as math.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 28 covered grass and occlusion. Twenty-eight parts built a world to stand in: terrain you can read, water you can swim, foliage that holds up to the horizon, a server that remembers what you changed. This part is about the thing that moves through all of it, and it's the payoff of the whole engine, because the goal isn't a player controller. It's a controller that doesn't care what body it's driving, where its animations came from, or whether a human or an AI is at the wheel. Spike 58 builds movement as a stack of pluggable behaviors over a physics engine that knows nothing about locomotion, then proves the architecture by running three different bodies through one copy of it. Spike 59 hangs a real retargeted avatar on that controller without changing a single line of it. Spike 60 hangs a different animation pack that needs no retargeting at all, and pulls the clip-picking logic out into something you can actually test.

A physics engine that knows nothing about walking

Open Spike 58 in a new tab ↗ · View source

The design rule is severe and it's the whole point: the capsule engine owns no locomotion. No walk, no run, no jump, no friction, no top-speed cap, not even gravity. It integrates a kinematic capsule against terrain and nothing more. Every locomotion behavior, walk, slide, glide, climb, swim, crouch, stamina, lives in a self-contained controller registered with the engine. Each frame the engine ticks every controller, asks each one whether it wants control, and lets the highest-priority claimant write velocity. Walk has no special status. It's just the lowest-priority controller that always says yes, so it's the default when nothing else fires. A controller is six small functions: a tick that updates its own internal state every frame even when it isn't active, a pure wantsControl predicate that claims the frame, an applyForces that only the winner runs and that writes velocity and applies its own gravity if it wants any, plus optional onEnter, onExit, and stateName. Swim returns ownsCollision: true from applyForces to take over terrain handling, because its buoyancy spring would otherwise fight the engine's foot-snap.

Even the things that aren't locomotion still leak through that contract, which is what forced the next idea. The piece that earns the architecture is channels. An earlier single-channel design ran everything through one arbitration, which meant a stamina tracker or a crouch stance had to pretend to be locomotion and then decline control with a wantsControl returns-false hack just to run its bookkeeping. The fix splits controllers into named channels that arbitrate independently and apply in a fixed order: resource, then stance, then locomotion. Resource runs first because its writes, like stamina decay, get read by the others. Stance runs second because crouch shrinking the capsule height has to land before walk reads it to cap top speed. Locomotion runs last and owns the per-frame velocity write. So a stamina observer and a crouch modifier and an active swim controller all coexist cleanly, each in its own channel, with no controller having to lie about what it is. The demo visualizes all of this with a bare capsule that changes color by active controller, so you can watch arbitration happen: green walk flips to orange on a steep slope as slide takes over, to cyan in the lake as swim wins, to cream midair when you tap glide.

One engine, three bodies

The real test of "owns no locomotion" isn't the player. It's whether the same engine, untouched, can drive something that isn't a player at all. createCapsuleEngine is a pure factory with no module-level state, no singletons, and no per-instance side effects, so the spike instantiates it three times. The player is one instance with the full controller set. A rideable horse is a second instance that registers only a walk controller, which is the entire idea made literal: a body's movement vocabulary is just whichever controllers you registered, so the horse is faster on the flat and physically can't climb, swim, or glide, because those controllers were never added. An autonomous NPC is a third instance, ticked every frame alongside the player, driven by a wander controller that synthesizes its own input so the body steers itself with no hands on the keyboard. The engine never learns that one of its bodies is a horse or that another is AI-driven. They're all the same capsule integrator with different controller lists.

Mounting is the one piece that deliberately lives outside the engine. Swapping control between the player and the horse means coordinating two engines, and a controller runs inside one engine and can't see across that boundary, so the mount logic sits at the host level: it's a small state machine that decides which engine gets stepped this frame, freezes the other, eases the rider onto the saddle with a smoothstep over three quarters of a second, and tells the camera which body to track. The engine factory never hears about any of it. That's the line the architecture draws and keeps. Behaviors that belong to one body are controllers; coordination between bodies is the host's job, and keeping those separate is why a fourth or fortieth body would cost nothing new.

Tested without a browser

Because the engine reaches for no window, no document, and no Three.js, the whole thing runs headless. The spike ships a Node harness that mocks the terrain interface, drives the engine frame by frame with scripted input, and asserts on the resulting state, so the regressions that are miserable to catch by play-testing get caught in a script instead: the jump-and-land transition, swim entry and exit thresholds, climb auto-clearing when a surface flattens, stamina drain rates. Feeding the same input and timestep sequence twice and checking for byte-identical output state pins the engine as deterministic, which is the property a networked build will eventually lean on. One regression the harness caught is worth keeping: stepping from walkable ground onto a steeper-than-walk slope used to engage the slide controller and bounce the player back up the hill. The fix was a descent gate. Sliding only starts if the capsule is actually falling onto the slope, so walking horizontally into a steep face now blocks cleanly instead of sliding, and the test that asserts "walking into a non-walkable slope blocks the player" keeps it fixed.

Plugging in a real avatar without touching the controllers

Open Spike 59 in a new tab ↗ · View source

Spike 59 is the test of whether the controller layer is really decoupled from the body. It swaps the colored capsule for a real skinned character, the 3MIKE FBX rig with Quaternius Universal Animation Library clips retargeted onto it, and the controllers don't change at all. The seam is a single string. Each controller already reports a state name through stateName, idle, walk, run, jump, fall, land, slide, glide, swim, swimIdle, and the avatar layer maps that name to a retargeted clip through an alias table and crossfades on switch. Walk picks its own sub-state dynamically from grounded plus vertical velocity plus horizontal speed, so a single walk controller drives idle, walk, run, jump, fall, and land, and the avatar just follows the reported name. Because this spike is single-player, the avatar drops the wire-integer indirection and multi-character abstraction from the earlier networked spikes and maps the state name straight to a clip. The proof is that the entire visual upgrade from capsule to rigged human touched zero lines of locomotion code, which is exactly what a pluggable controller is supposed to buy.

A pack that needs no retargeting, and a picker you can test

Open Spike 60 in a new tab ↗ · View source

Spike 60 plugs in a third body, Synty's POLYGON Base Locomotion pack, and the loader is almost nothing. Each clip ships as a standalone FBX carrying an embedded copy of the same Synty skeleton plus one baked animation, and because the character rig and every clip use identical bone names, you grab the clip off fbx.animations[0] and play it directly on the character's mixer with no retargeting library in the loop. Three.js resolves animation track targets by bone name rather than object identity, so a Synty or Mixamo-style pack authored against the matching rig just works. That's the deliberate contrast with the UAL path from the previous spike, which needs heavyweight retargeting because the source clips and the target rig were authored against different skeletons. Same controller, same state-name seam, two completely different animation pipelines behind it.

The other half of spike 60 is making the clip-picking logic testable. Choosing which clip to play is full of judgment thresholds, and that logic had been buried inside the avatar layer next to FBXLoader and the DOM where it couldn't be exercised. The spike extracts the picker into pure functions that touch neither Three.js nor the window: they take a plain player record (velocity, horizontal speed, facing, grounded, ground normal, impact velocity) and a clip-action stand-in, and return a clip alias string. That lets the thresholds live as named, asserted constants. Jump splits into walking, running, and sprinting variants by speed buckets aligned with the walk controller's actual sprint threshold; landings split into soft, medium, and hard by impact velocity; uphill and downhill clip variants fire from a slope-projection dot product with a flat-clip deadzone below about seven degrees; an idle-to-locomotion bridge always resolves forward so a standing start never plays a clip backward; and a stop bridge is gated by a minimum time-in-loop, because Synty's foot-phase stop clips contain about a second of authored deceleration that looks ridiculous tacked onto a step the player barely took. A small state debouncer holds off the fall state for a few frames so a one-frame loss of ground contact across a seam doesn't flicker the animation. Pulling all of that out of the rendering shell means the rules can be unit tested without a GPU, the same headless discipline the engine itself got in spike 58, which is the difference between locomotion feel you tune by guessing and locomotion feel you can pin down.

Technology referenced in this chapter

A locomotion-free physics engine. The capsule engine integrates a kinematic body against terrain and owns no walk, run, jump, friction, speed cap, or gravity. Every behavior is a registered controller exposing tick, wantsControl, applyForces, and optional onEnter/onExit/stateName. Walk is just the lowest-priority always-yes default, and a controller can return ownsCollision: true to take over terrain handling (swim does, so its buoyancy spring doesn't fight foot-snap).

Independent arbitration channels. Controllers register into named channels (resource, stance, locomotion) that arbitrate separately and apply in a fixed order, so observers like stamina and modifiers like crouch coexist with active locomotion instead of faking control and declining it. Resource writes (stamina) are read by stance and locomotion; stance writes (crouch capsule height) are read by locomotion's speed cap; locomotion runs last and owns the velocity write.

One factory, many bodies. createCapsuleEngine is a pure factory with no singletons, so the same engine drives the player, a walk-only rideable horse, and a self-steering NPC fed synthetic input. A body's movement vocabulary is exactly its registered controller set, so the horse can't climb or swim because those controllers were never added. Mounting lives at the host level, not in a controller, because it coordinates two engines that can't see across each other. See GPU-driven LOD.

Headless, deterministic testing. The engine touches no window, document, or Three.js, so a Node harness drives it frame by frame and asserts on jump-and-land, swim thresholds, climb auto-clear, and stamina drain. Replaying identical input twice and checking for identical output proves determinism, and a regression test pins the descent gate that stops a horizontal walk into a steep face from sliding the player backward.

Body-agnostic avatar binding with a testable picker. Controllers report a state-name string and the visual layer maps it to a clip, so swapping a capsule for a retargeted 3MIKE + UAL avatar touches zero locomotion code. Synty POLYGON clips share bone names with the rig and play with no retargeting (Three.js binds tracks by bone name), unlike the UAL path's heavyweight retargeting. The clip picker is extracted into pure functions with named constants for jump speed buckets, landing severity, slope-projection variants, an always-forward idle bridge, a stop-bridge minimum-time guard, and a fall-state debouncer, so locomotion feel is unit-testable rather than guessed.

Part 29 of 30. Previous: Part 28 - Grass to the horizon, and ground that hides itself Next: Part 30 - A camera that respects walls Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 27 built the island and gave it ground that doesn't look tiled. This part covers the two things that make terrain feel inhabited rather than empty. Spike 56 is grass, the surface detail that turns a textured slope into a place you'd walk through, and the problem is making a field read as a field instead of scattered streaks. Spike 57 is the opposite of drawing more: it's about not drawing what a hill is already hiding, and the interesting result is that the fast way to test for it turned out to be the correct way too.

Grass that reads as a field, not confetti

Open Spike 56 in a new tab ↗ · View source

The core decision is geometric. A single thin tapered blade is sub-pixel from most camera angles, so half a million flat blades read as sparse green confetti rather than a field. The fix is a cross-quad clump: three tapered quads rotated sixty degrees apart around the local up axis, so from any viewing direction at least one quad sits nearly perpendicular to the camera and each instance covers roughly three blade-widths of actual screen area. That's the difference between seeing green streaks and seeing grass.

A WebGPU compute kernel places every clump once at init. It hashes the instance index into five decorrelated random streams, picks an XZ position inside the patch, samples ground height from the same FBM the CPU ground mesh uses (a TSL port with sign-preserving mod so the values match exactly and blades sit on the surface rather than floating above it), takes a central-difference normal, and rolls a per-clump width, height, and hue. The render side is a TSL vertex graph that bypasses the instance matrix entirely and writes straight to clip space: it scales the unit cross-quad, rotates local up onto the ground normal with Rodrigues' formula, and translates to the clump position. Distance LOD comes for free without a culling pass, because the vertex graph multiplies the clump's height by $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$, so far clumps collapse flat to zero height and stop costing fill. Wind is two octaves of sin and cos over the clump's world XZ plus time, applied horizontally and gated by the height fraction so the base stays anchored while the tips move, and a tiny camera-aware lean tips each clump toward the viewer so they open up perspectivally instead of reading as flat cards.

The color recipe is borrowed from NedMakesGames' Breath of the Wild URP shader: flat shading with the blade color a lerp from a root tone to a tip tone along the height fraction, where the root and tip tones are themselves lerped between two palettes by the per-clump hue value. That gives the dappled two-tone look a real BotW grass field has. Diffuse uses the ground normal against the sun with an ambient floor, because the cross-quad's per-quad normals are too noisy to shade individually for a stylized look. The whole field is one draw, placed and animated entirely on the GPU.

Four ways to cull what a hill is hiding

Open Spike 57 in a new tab ↗ · View source

Spike 57 benches four culling paths over the same procedural world the production client streams, scaled 1.8x vertically so hills actually occlude foliage. T0 is distance-only, matching what the shipping chunk visibility already does. T1 adds frustum culling, the single biggest cheap win, dropping everything outside the view cone. T2 adds a terrain-aware horizon test: march a ray from the eye to each instance and reject it if the heightmap rises above the ray anywhere along the way, so a tree behind a ridge gets culled even though it's inside the frustum. T3 keeps the same horizon test but accelerates it with a max-height pyramid, and T4 ports the whole distance-plus-frustum-plus-horizon test to a TSL compute kernel that writes a per-instance visibility scale the foliage material reads to collapse hidden vertices. A two-frame stay-visible counter smooths the single-frame flicker when a sample point lands just inside or outside a texel as the camera nudges, kept short on purpose because anything longer masks algorithmic bugs instead of fixing them.

The pyramid is where the spike earns its keep, and the lesson is about matching the test to what's actually on screen. The rendered terrain is a triangle mesh with vertices on a fixed two-meter grid, and between vertices the rasterizer interpolates linearly, so the real rendered height inside any rectangle is the max of the vertices inside it, never the continuous noise peak between them. If the occlusion pyramid samples the noise at a finer grid, it finds phantom peaks the mesh never displays and starts blocking rays the camera can plainly see through. So the pyramid's base texels sit exactly on the vertex grid, each storing the max of its four corner vertices, and upper levels are textbook 2x2 max reductions, which makes it exact with respect to the rendered mesh. For the per-step ray test the code deliberately point-samples the mesh with bilinear interpolation rather than querying the pyramid, because a sub-texel AABB query returns the whole texel's max and inflates the height by several meters on steep ridges, which is exactly the over-occlusion that would hide visible props.

The surprising result is that T2, the brute-force reference, is the one that's wrong. Because T2 point-samples the continuous noise directly, it catches peaks between mesh vertices that don't render, so it over-occludes slightly and hides foliage the player can actually see. The pyramid path is both faster, because of the $O(\log N)$ AABB reduction for chunk-level tests, and more geometrically correct, because it can only ever return heights the mesh truly displays. That's the spike's whole point: the accelerated structure isn't a quality compromise you accept for speed, it's the version that matches reality. Chunk culling runs a five-point test per chunk (four top corners plus center at the chunk's max height) and excludes each chunk's own footprint from the occluder set so a chunk never occludes itself. The recommended production path is T4: push the instance metadata and height field into storage buffers and run the identical loop in a compute shader with an indirect draw, since the renderer is moving to WebGPU anyway.

Technology referenced in this chapter

Cross-quad GPU grass. Three tapered quads rotated sixty degrees apart per clump guarantee one near-perpendicular quad from any angle, so half a million instances read as a field rather than sub-pixel confetti. A compute kernel places every clump (FBM ground height sampled with the same sign-preserving mod as the CPU mesh, central-difference normal, per-clump size and hue), and a TSL vertex graph bypasses the instance matrix to scale, Rodrigues-rotate onto the normal, translate, and apply height-gated wind. Distance LOD is free: clumps collapse to zero height by $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$. Color follows NedMakesGames' BotW recipe, a root-to-tip gradient over two hue-mixed palettes. See GPU-driven LOD.

Terrain horizon occlusion culling. Four benched paths over the production world: distance, plus frustum, plus a heightmap ray test that rejects instances behind a ridge, plus a max-height pyramid that accelerates it, plus a TSL compute port. The pyramid samples on the exact two-meter vertex grid the mesh tessellates on (base texel = max of four corner vertices, 2x2 max-reduce upward), so it returns only heights the rasterizer actually displays.

Accelerated and correct, not a trade. Point-sampling continuous noise (the brute-force T2 path) finds peaks between mesh vertices that never render, over-occluding visible foliage. The vertex-grid pyramid is both faster ($O(\log N)$ AABB reduction) and geometrically exact, so per-step ray tests bilinear-sample the mesh rather than querying the pyramid's per-texel max, which would inflate heights by meters on steep ridges. Chunk culling uses a five-point test and excludes each chunk's own footprint so it never self-occludes. The production path pushes metadata and the height field into storage buffers for a compute-shader cull with indirect draw.

Part 28 of 29. Previous: Part 27 - An island from noise, ground that looks like ground Next: Part 29 - One controller, any body Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 26 put water on the world. This part builds the land under it, in two stages that mirror how a real place comes to be. Spike 54 is the terrain itself: not sculpted by hand but grown from noise, then weathered until it has the drainage and the coastline of somewhere that water has actually run across. Spike 55 is the skin on that terrain: solving the problem that defeats almost every procedural ground, which is that a tiled texture looks tiled. The two together answer one question, can a creator get a plausible island and ground that reads as ground without an artist touching either, and the answer is yes if you copy the right recipes.

A coastline that noise alone won't give you

Open Spike 54 in a new tab ↗ · View source

The heightmap follows the Red Blob Games recipes, which are a stack of small transforms each fixing a specific flaw in raw noise. Fractional Brownian motion sums several octaves of Perlin noise so the terrain has both broad hills and fine detail, but plain FBM looks soft and grid-aligned, so the sample point gets domain-warped first: you offset each coordinate by another noise field, $p^{\prime }=p+\text{noise}(p)\cdot s$, which bends the ridges into something organic instead of axis-locked. Then redistribution, raising elevation to a power $e^k$, pushes the midtones down so the world has flat valleys and sharp peaks rather than everything sitting at the same gentle slope. The piece that makes it an island rather than infinite hills is a radial falloff: compute a euclidean distance from center, $d=min(1,\sqrt{n_x^2+n_y^2})$, and blend the elevation toward $1-d$ so the terrain drops into ocean at the edges. A second independent noise field becomes a moisture map, which does nothing for the shape but feeds the biome step later.

That gets you a shape, but it's a noise shape. It has no rivers, no valleys cut by water, no sediment fans, because nothing has ever flowed across it. The fix is hydraulic erosion, ported from Sebastian Lague's MIT-licensed implementation. Thousands of water droplets spawn at random and roll downhill, each carrying inertia so it doesn't make hard right-angle turns, picking up sediment when it speeds up and depositing it when it slows or pools, with a precomputed circular brush spreading each erosion event over a small radius so the carve is smooth rather than a one-pixel scratch, and evaporation that retires the droplet over its lifetime. Run enough droplets and the terrain grows the thing noise can't fake: drainage networks that converge, valleys that widen downstream, and flats where sediment settled.

Erosion on the GPU, and rivers that know where they are

The CPU erosion is correct but slow, so the spike also ports it to a WebGPU compute shader, and the interesting part is what GPU atomics force on you. Heights are stored as fixed-point i32 with a scale of one million, because WGSL has no atomic add on floats, and the only way thousands of droplets can deposit and remove sediment from the same cell in parallel without races is atomicAdd and atomicSub on integers. The fixed-point round-trip means a cell can occasionally go slightly negative under heavy concurrent drag, which is harmless and clamped on readback. The CPU version precomputes a per-cell brush table, but at a ${1001}^2$ grid that table is around 100 MB, so the GPU port recomputes each droplet's brush on the fly instead, trading a little arithmetic for a lot of memory. Droplet start positions still come from the CPU through a Mulberry32 generator so runs are deterministic.

Two more passes turn weathered terrain into a readable map. Drainage uses the Red Blob D8 flow-accumulation method: drop one unit of rain on every cell, sort all cells by elevation descending, and pass each cell's accumulated water to its single lowest neighbor, so water piles up along the natural valleys, and any cell whose accumulation crosses a threshold is marked river. The catch is that an eroded heightmap has pits, local depressions with no downhill exit, and water entering a pit just stops, breaking the accumulation. So before drainage runs, Planchon-Darboux pit filling raises each pit to just above its lowest neighbor, $\text{minNeighbour}+ϵ$, iterating under twenty passes until every cell has somewhere to drain. Finally biomes are assigned the Red Blob way, a two-axis lookup on elevation against moisture so a high-and-dry cell becomes rock while a low-and-wet one becomes marsh, with slope-aware overrides on top: steep faces force to rock regardless of moisture, the waterline band becomes beach, and the highest elevations take snow. The result is an island you can read at a glance, generated end to end from two noise seeds.

The tile that won't stop repeating

Open Spike 55 in a new tab ↗ · View source

A terrain needs a material that covers kilometers from a texture that's a couple of meters across, and the moment you scale a tile up to cover ground, the eye locks onto the repetition. Spike 55 is an A/B bench of four sampling modes on the same geometry and lighting, so the only variable is how the texture is read. The baseline is plain: one sample at the scaled UV, which tiles obviously every few meters and exists only as the thing to beat. The free PBR layers come from Poly Haven over their CDN, diffuse plus the packed ARM map (ambient occlusion, roughness, metalness) plus a GL normal, all CC0, loaded with anisotropy 8 and mipmaps.

The interesting three are different attacks on the repeat. The hex-linear mode is the Heitz-Neyret triangle grid: lay a skewed triangular lattice over the surface, and each fragment sits inside one triangle whose three vertices each take a randomly offset tap, blended by barycentric weights so neighboring regions sample different parts of the texture and the large-scale tiling dissolves. But a plain linear blend of three taps averages their colors at the triangle edges, which leaves a visible triangular pattern, the exact artifact spike 48 ran into. The hex-vp mode is the published fix from the same 2018 paper: after the barycentric sum, subtract the texture's mean color, rescale by the inverse square root of the sum of squared weights to hold variance constant, then add the mean back. That keeps contrast steady across the blend so the triangles vanish, which is why the material does a 1-by-1 readback of each loaded texture to estimate its mean color up front. The fourth mode, iq-untiled, is Inigo Quilez's Texture Repetition technique 3: two offset taps blended by a low-frequency variation pattern, only two samples instead of three and no triangle structure to begin with, the cheap option that holds up.

On top of any mode sits optional triplanar projection, which is what lets the same material wrap a cliff without stretching. Instead of one UV, the shader samples three world-axis projections, the X-facing surfaces read the YZ plane, Y reads ZX, Z reads XY, and blends them by abs(normalWorld) raised to a sharpening power between four and eight so a 45-degree slope doesn't ghost all three projections into mush. The bench makes the tradeoff legible: variance-preserving hex blending is the quality winner and Quilez's two-tap is the performance-conscious one, and both beat plain by a wide enough margin that no creator should ever ship the plain tile.

Technology referenced in this chapter

Recipe-stacked heightmap generation. Red Blob Games recipes compose raw noise into terrain: domain-warped FBM ($p^{\prime }=p+\text{noise}(p)\cdot s$) for organic ridges, $e^k$ redistribution for flat valleys and sharp peaks, and a euclidean radial falloff blended toward $1-d$ to drop the edges into ocean and make an island. A second noise field is the moisture map for biome assignment. See landscape generation.

Hydraulic erosion, CPU and GPU. Sebastian Lague's droplet model (inertia, carrying capacity, a precomputed circular deposit brush, evaporation) carves real drainage that noise can't fake. The WebGPU compute port stores heights as fixed-point i32 at a scale of one million so droplets can atomicAdd/atomicSub the same cell in parallel, recomputes each droplet's brush on the fly to avoid a ~100 MB table at ${1001}^2$, and seeds start positions from a deterministic Mulberry32 generator.

D8 drainage with pit filling. Red Blob D8 flow accumulation drops one unit of rain per cell, sorts cells by descending elevation, and passes water to each cell's lowest neighbor, marking rivers above a threshold. Planchon-Darboux pit filling first raises every local depression to $\text{minNeighbour}+ϵ$ (iterating under twenty passes) so water never gets trapped and accumulation stays connected. A two-axis elevation-by-moisture lookup assigns biomes, with slope overrides forcing rock on cliffs, beach at the waterline, and snow on peaks.

Breaking texture tiling four ways. On identical geometry and lighting: plain (one tap, tiles obviously), hex-linear (Heitz-Neyret triangle grid, linear blend leaves a triangle pattern), hex-vp (the EGSR 2018 §3.3 variance-preserving fix that subtracts the mean, rescales by inverse-sqrt of squared weights, and re-adds the mean, needing a 1×1 mean readback per texture), and iq-untiled (Inigo Quilez two-tap technique 3). Triplanar projection samples three world-axis planes blended by abs(normalWorld) to a power of 4-8 so cliffs don't stretch. Variance-preserving wins on quality, two-tap on cost. See terrain materials.

Part 27 of 29. Previous: Part 26 - Three ways to make water Next: Part 28 - Grass to the horizon, and ground that hides itself Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 25 dressed the avatars. This part is about water, and it's three spikes because water is the surface where a cheap shortcut and the correct answer look identical in a screenshot and completely different in motion. Spike 51 builds reflection the screen-space way, the tempting one, and runs straight into its built-in limitation. Spike 52 switches to the method every shipping game actually uses. Spike 53 drops in a finished water library to see how far "done" is from where we are. All three share one refraction layer, so the only variable that moves between the first two is how the reflection gets computed.

Reflection from the screen you already have

Open Spike 51 in a new tab ↗ · View source

Screen-space reflection reuses the frame you already rendered. For each water pixel, you reflect the view ray off the surface, march that reflected ray through the depth buffer, and when the ray passes behind a recorded surface you've found what the water reflects, sampled straight from the color buffer. The port follows three.js's SSRNode line by line, which in turn follows lettier's SSR primer. The march is a DDA walk in screen space: project the ray's start and end to pixel coordinates and step along whichever axis is longer, one tap per pixel. The reflected ray's depth at each step needs perspective-correct interpolation, $\frac{1}{1/z_0+s(1/z_1-1/z_0)}$, because linearly interpolating view-Z is simply wrong and produces hits in the wrong place.

Two things make this usable rather than a slideshow. The coarse march is capped at 64 steps, because a long ray that projects across a thousand pixels would otherwise run hundreds of iterations per fragment, and a million-fragment water plane times hundreds of iterations times a few texture samples is a 30 fps scene. Quality controls the effective stride within that cap instead of the iteration count. And because a capped coarse march leaves visible stair-step banding, a six-iteration binary refinement bisects the interval between the last miss and the hit, which is 64x sub-step accuracy, enough that neighboring water fragments stop locking onto the same coarse hit position. A final point-to-line distance check confirms the candidate is genuinely on the reflection ray rather than just at the same depth, with a thickness tolerance that auto-scales to the view-space width of one pixel at that depth, tighter up close and looser far away.

The honest part of this spike is written into its own comments: SSR cannot reflect what the main camera never sampled. A tree's underside, anything off-screen, anything occluded, none of it exists in the buffers, so it can't appear in the reflection. That's the "wrong-side information loss" that no amount of march quality fixes, and it's exactly why the next spike exists.

The mirror that can't lie

Open Spike 52 in a new tab ↗ · View source

A planar reflection renders the scene a second time from a camera mirrored across the water plane, into an offscreen target, and the water shader samples that target. This is the canonical pattern, what UE5 Water, three.js's own WaterMesh, ABZÛ, and Sea of Thieves all use, because it has every pixel of the scene to draw from, including the geometry SSR can never see. In TSL it's almost anticlimactic: reflector() allocates the mirrored helper camera and its render target, you add its target to the mesh so it updates each frame, and you sample its color. When waves come later, the reflection wobbles by adding a distortion offset to the reflector's UV node, which is exactly the line WaterMesh uses.

The bug worth recording was in the safety net, not the mirror. An earlier version blended the reflector's output with a procedural sky as a fallback, weighted by the magnitude of the reflected color, on the theory that a near-zero reflection meant the target had nothing there. But a dark canopy shadow also has a low magnitude, so the clamp never reached full strength and those genuinely dark pixels got mixed with bright sky. The symptom the user caught was precise: the raw mirror target in debug mode showed perfect dark trees, while the composed render had washed-out reflections, and the diagnosis was that the shader "vanishes dark colors." The fix was deletion. The reflector target is reliable after the first frame, so there's no need for a fallback at all. Both spikes share the same refraction underneath: sample the scene behind the surface, reconstruct how far below the waterline each pixel sits, and apply per-channel Beer-Lambert extinction so red dies within a few meters while blue persists, with a sky mask so the far-plane backdrop doesn't get fogged. Schlick Fresnel mixes refraction when you look straight down into the water with reflection when you look across it.

What finished looks like

Open Spike 53 in a new tab ↗ · View source

Spike 53 is the build-versus-buy check. It drops in threejs-water-pro as it ships, with its tropical preset, default ocean clipmap, camera tracking, and Rayleigh sky, and loads the same island glTF the library's own demo uses. The point is to see the gap between a hand-rolled flat-water shader and a full ocean system, and the gap is large: this one has a buoyancy system that samples wave height at several points under a ship's hull so it pitches and rolls instead of just bobbing, a wake generator, shoreline and surface foam, and a mask pass that suppresses water rendering inside the ship's hull so ripples don't bleed through the deck.

Integrating it surfaced the kind of detail you only learn by using a library rather than reading its README. Foam textures are referenced by filename in the preset but loading them is the consumer's job, and without them the shoreline reads as a hard waterline edge instead of breaking surf. The island is positioned so its underwater geometry drops past the ocean floor, letting the library's floor mesh occlude the model's outer ring with no visible plane edge, which is the library's intended pattern: bring a 3D model, don't synthesize terrain. And antialiasing is deliberately off on the renderer in favor of a post-process FXAA pass, because MSAA blends edge fragments against the background before the depth-aware atmospheric fog runs, leaving a thin dark fringe wherever geometry meets fog. Resolving aliasing after the fog instead of before it removes the fringe. What this de-risks is the decision itself: a production ocean is a large, specialized system, and for the cases where we need one, adopting a maintained library beats rebuilding wakes and buoyancy and foam from scratch, while the planar-mirror shader from spike 52 stays the right answer for the smaller inland water a creator places in their own world.

Technology referenced in this chapter

Screen-space reflection water. A reflected view ray marches the depth buffer in screen space via DDA, using perspective-correct 1/z interpolation, a hard step cap to bound the per-fragment cost, and a binary refinement pass to remove the banding a capped march leaves. A point-to-line confirmation with depth-scaled thickness rejects false hits. The method's hard limit is that it can only reflect geometry the main camera already sampled, so off-screen and wrong-side surfaces never appear. See terrain materials.

Planar mirror reflection. A helper camera mirrored across the water plane renders the scene into an offscreen target that the water shader samples, giving pixel-perfect reflections including geometry SSR can't see. This is the pattern UE5 Water and three.js WaterMesh use, with wave distortion applied as an offset to the reflector's UV node. A magnitude-weighted sky fallback wrongly erased dark reflection pixels; the reflector target is reliable after the first frame, so removing the fallback was the fix.

Beer-Lambert depth tint refraction. Both shaders sample the scene behind the surface, reconstruct each backdrop pixel's depth below the waterline, and apply per-channel exponential extinction (red dies in meters, blue persists) composited toward a water-fog color, with a sky mask so the far plane isn't fogged. Schlick Fresnel blends refraction at normal incidence with reflection at grazing angles.

Adopting a production water library. threejs-water-pro ships an ocean clipmap, Rayleigh sky, multi-point buoyancy for ship pitch and roll, wakes, foam, and a hull mask pass. Consumer-side details matter: foam textures must be loaded explicitly, island underwater geometry should drop past the ocean floor so the floor occludes its edges, and antialiasing should run as a post-process FXAA pass rather than MSAA to avoid a dark fog fringe at geometry edges.

Part 26 of 29. Previous: Part 25 - One skeleton, every outfit Next: Part 27 - An island from noise, ground that looks like ground Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

A forest is one of the worst things you can ask a GPU to render. Each leaf is a textured quad with an alpha mask cut out of it. Dozens of those quads stack on top of each other along every view ray. The rasterizer has no way to know in advance which fragments will pass the alpha test, so the standard early-Z optimization that saves opaque scenes is mostly turned off. The result is that a single screen pixel can run the full leaf shader 10 or 15 times before the frame settles. That's foliage overdraw, and it's the single most expensive part of an open-world frame in any game shipped in the last decade.

The good news is that it's a solved problem. Not in the sense that anyone fixed it with one trick, but in the sense that there's a stack of seven or eight techniques that, combined, take effective overdraw from 8-15x in a dense forest down to 1-2x. Every modern engine ships some version of this stack. Here's what's in it, why each piece exists, and the canonical references for each.

1. Why foliage overdraw is so painful

In a typical opaque scene, the GPU does early depth rejection: before the pixel shader even runs, the hardware checks the existing depth buffer and skips fragments that are already behind something. This is essentially free and it's what keeps the cost of dense geometry sane.

Alpha-tested foliage breaks this. The fragment shader has to actually run to evaluate the alpha texture and call discard (or clip) on the masked-out pixels. The hardware can't know whether a fragment will be killed until after the shader runs, so on most GPUs the use of discard anywhere in a shader disables early-Z for that draw call entirely. On tile-based GPUs (mobile, M-series, some consoles) it can disable Hi-Z and depth compression for the whole frame. The pixel shader runs once for every triangle that covers a pixel, and most of those evaluations end with a discard.

Stack 10 leaf quads in front of a single screen pixel and the leaf shader runs 10 times. Multiply by 4 million pixels and the cost is brutal. Marco Salvi's writeup To Early-Z, or Not To Early-Z is the gentlest tour of why this happens at the hardware level, and it's the right place to start if you've never thought about it before.

2. The depth prepass for masked geometry

The biggest single win, and the technique every modern engine ships, is splitting the foliage draw into two passes. The first pass writes only depth, with a minimal shader that does the alpha test, discards the masked pixels, and writes nothing else. The second pass renders the full material with depth testing set to "equal" and depth writes off. Each visible pixel now shades the full BRDF exactly once, no matter how many leaf quads were stacked behind it.

This sounds like double work because you're touching the same triangles twice, but the prepass shader is so cheap (one texture sample, one discard, one depth write) that the savings on the main pass dwarf the extra cost. In a dense forest the main pass goes from running the full leaf shader 10-15 times per pixel to running it exactly once.

Unreal, Frostbite, Decima, and the modern Rage and Dunia branches all do this. It's also the key reason masked materials are still cheaper than translucent materials in any of these engines.

Deep dives:

• Pettineo, To Early-Z, or Not To Early-Z (the canonical writeup of how discard interacts with Hi-Z and early-Z).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, the Frostbite depth-prepass and prepass-driven culling architecture).
• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, with Decima's two-pass foliage rendering).
• Persson, A couple of notes about Z (still one of the clearest explanations of depth-equal testing and prepass economics).

3. Aggressive LODs and octahedral imposters

The second-biggest win is never drawing the leaves at all when you don't have to. Foliage assets ship with several LOD tiers. The closest is the full mesh with individual leaf cards. At medium range, the leaves collapse into denser composite cards (a clump of 30 leaves becomes 1 textured card with the same silhouette). Beyond a distance threshold, the entire tree becomes an imposter: a small piece of geometry textured with pre-rendered views of the tree from many angles.

The modern imposter format is the octahedral imposter: an 8-faced piece of geometry textured with an atlas of views captured from points on a sphere using octahedral mapping. At runtime, the shader picks the closest two or three pre-rendered views based on the camera direction and blends between them. The result is a few-triangle stand-in that looks 3D from any angle and can have proper shading, normal maps, and even wind animation. Ryan Brucks' implementation, originally a community plugin and now part of Unreal, is the reference. Microsoft Flight Simulator's billion-tree forests are essentially octahedral imposters everywhere except the camera.

The bigger structural win is that imposters are opaque or near-opaque at distance. The 30-leaf composite card is a single masked quad instead of 30 quads. The whole-tree imposter is a few faces, not thousands. Far-field overdraw collapses to almost nothing.

Deep dives:

• Brucks, Octahedral Impostors (the canonical reference, with the math and the UE implementation).
• Halen, Octahedral Impostors in Unreal Engine (the integrated UE workflow).
• Häggström, Real-Time Rendering of Vegetation (a clean thesis covering LOD chains, imposters, and the math behind them).
• Crytek, SpeedTree integration in CryEngine 3 (GPU Gems 3, still the best primer on tree LOD chains).

4. Cluster and GPU-driven culling

Even with a depth prepass, the prepass itself has a cost: it still has to touch every triangle of every visible (or potentially visible) tree. Modern engines push that cost down with GPU-driven cluster culling, which throws away whole groups of triangles before the rasterizer ever sees them.

The pipeline looks like this: every mesh is pre-split into clusters of 64 or 128 triangles with a tight bounding box and a cone of normals. At render time, a compute shader walks the instance list, frustum-tests each instance, then frustum-tests every cluster of every visible instance, then Hi-Z occlusion-tests each surviving cluster against the previous frame's depth pyramid. Whole branches of trees that are hidden behind a hill or in front of another tree get culled before any vertex shader runs. The output is a compact list of "draw these clusters" arguments fed straight into a single DrawIndirect call.

This is what makes a forest of 10,000 trees render in milliseconds instead of seconds. Ubisoft's Assassin's Creed Unity talk introduced this pipeline in production form (20-40% triangles culled, 30-80% shadow triangles culled, 10x more instances on screen than the previous generation), and Wihlidal's Frostbite talk took it further. UE5 Nanite is the visible end-state of this trajectory: cluster culling all the way down to the pixel.

Deep dives:

• Haar and Aaltonen, GPU-Driven Rendering Pipelines (SIGGRAPH 2015, the foundational Assassin's Creed Unity talk).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite's GPU-driven prepass).
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, cluster culling at meshlet granularity).
• Liktor, Geometry Rendering Pipeline Architecture at Activision (the Call of Duty version of cluster culling, 2021).

5. Front-to-back instance and cluster sorting

Once the prepass is doing its job, order starts to matter. The prepass writes depth, but only for fragments that pass the alpha test. If you draw the back of the forest first and the front last, every front fragment overwrites a back fragment, and the prepass shader still runs for the back. If you draw front-to-back, each successive draw fills more of the depth buffer with smaller values, and Hi-Z rejects more and more of the back fragments before the shader runs.

This is why almost every modern engine sorts foliage instances by distance to camera before issuing the prepass. The sort is cheap (a few hundred thousand instances on the GPU using a radix sort), and it turns the prepass itself into a self-pruning operation. Cluster-level culling sorts at the meshlet granularity for the same reason. The depth prepass and front-to-back ordering are the kind of pair where each is good and the combination is great.

Deep dives:

• Persson, Depth in-depth (the architectural notes on depth-buffer ordering, prepass economics, and Hi-Z behavior).
• Giesen, A trip through the graphics pipeline (the deep technical explanation of how Hi-Z reject rate depends on draw order).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, includes Frostbite's GPU-side instance sort).

6. Dithered LOD transitions and hashed alpha

The other big trap is fading. The naive way to transition between two LODs (or to fade an instance in or out as the camera approaches) is alpha blending. But blended geometry can't write to the depth buffer, which kicks every fading tree into the slow translucent path and breaks the prepass. The solution is to keep the geometry in the masked path and do the fade inside the alpha test.

Two main techniques:

• Dithered LOD transitions sample a 4x4 or 8x8 Bayer pattern (or a screen-space blue-noise texture) and use that as a per-pixel cutoff modifier. A tree at 50% blend has a checkerboard of pixels surviving; the missing pixels are filled in by the next LOD's complementary checkerboard. TAA resolves the checker into a smooth blend across two or three frames. Cheap, stable, blends with everything else in the engine.
• Hashed alpha testing (Wyman & McGuire, I3D 2017) replaces the fixed 0.5 alpha threshold with a per-pixel hashed threshold in [0,1). Distant alpha geometry that would normally vanish entirely (because the mipmapped alpha drops below 0.5) keeps a stable scattering of surviving pixels. TAA again does the cleanup.

Both techniques keep foliage in the opaque/masked path where the depth prepass works, so you don't pay the full translucent rendering cost just to fade something in. Alpha to coverage is the MSAA-era cousin of the same idea: convert alpha into a sub-pixel coverage mask, get partial transparency without leaving the masked path. The catch is that A2C only really shines with MSAA, which most modern deferred renderers no longer use.

Deep dives:

• Wyman and McGuire, Hashed Alpha Testing (I3D 2017, the canonical hashed-alpha paper).
• Castaño, Computing Alpha Mipmaps (The Witness blog, the right way to mip alpha-tested textures so distant trees don't vanish).
• Yuksel, Alpha Distribution for Alpha Testing (a more recent improvement on alpha mipmaps).
• NVIDIA, Anti-Aliased Alpha Testing (a survey of A2C, hashed alpha, and dithered alternatives).

7. Reducing shading cost on masked pixels

Even with a perfect prepass and perfect culling, you still have to shade every visible foliage pixel once. Engines reduce that cost too:

• Cheaper BRDF. Foliage is matte and doesn't really need a full Cook-Torrance specular path. A wrapped-Lambertian diffuse plus a one-line specular approximation is plenty.
• Lower-frequency normal maps. Leaves are noisy already. A 256x256 normal map looks the same as a 1024x1024 one at typical viewing distances and saves bandwidth.
• No parallax, no anisotropy, no clearcoat. The PBR feature menu gets switched off for leaves.
• Two-sided thin transmission instead of full subsurface scattering. Leaves transmit light from behind, but you can fake it with a single back-light dot product.
• Half-resolution shading in some engines. Foliage gets shaded at 1/4 or 1/2 pixel rate and upscaled. Stochastic noise from TAA hides the resampling.
• Skip detail textures and decals on masked materials by default.

Each of these is a small win individually. Combined, masked-foliage shaders can run 2-3x faster than the equivalent opaque material.

Deep dives:

• Lagarde and de Rousiers, Moving Frostbite to Physically Based Rendering 3.0, sections on foliage and translucency (SIGGRAPH 2014, the canonical PBR adjustments for thin two-sided materials).
• Jimenez, Next Generation Character Rendering (the wrapped-Lambertian and back-translucency math, originally for skin but ported widely to leaves).
• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, with Decima's foliage shader simplifications).

8. Visibility buffers and Nanite for masked materials

The cleanest answer to overdraw is to decouple shading from rasterization entirely. A visibility buffer rasterizes geometry into a thin buffer (just triangle ID and instance ID per pixel), then runs the full material as a deferred pass that reads the visibility buffer and shades each pixel exactly once. There is no overdraw at the shading stage, by construction. Burns and Hunt's 2013 paper introduced this; UE5 Nanite is the production-quality realization, including for masked foliage as of UE 5.5.

Nanite's twist is that it does this with cluster-level virtualized geometry, so the rasterizer itself runs on a software path for sub-pixel triangles and keeps overdraw bounded. Masked materials in Nanite need the "programmable raster" feature: the alpha test runs during the visibility-buffer pass, but the material shading still happens once per visible pixel in the deferred resolve. The result is that very dense Nanite foliage, once notorious for being slow on masked materials, is now competitive with opaque or even cheaper, because the overdraw at shading time is zero. There's a tradeoff: it's often better to push high-poly opaque tree geometry through Nanite than to keep low-poly masked-card trees, because the masked path adds programmable-raster cost.

Deep dives:

• Burns and Hunt, The Visibility Buffer: A Cache-Friendly Approach to Deferred Shading (JCGT 2013, the original paper).
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, the production architecture).
• Epic, Nanite GPU Driven Materials (GDC 2024, with the masked-material and programmable-raster pipeline).
• Notes from "Nanite GPU Driven Materials" (a clean third-party walkthrough of the same talk).

9. Separate shadow representations for foliage

Shadow maps for alpha-tested foliage are the second-most-expensive shadow problem in any open-world frame, after large cascades. Every cascade needs its own depth prepass, every prepass runs the alpha test, and the cost stacks fast across 4 cascades and dozens of light frusta. So most engines don't render foliage shadows the same way they render foliage color.

Common substitutions:

• Mesh distance-field shadows (UE Lumen, custom engines). Each mesh has a precomputed signed distance field. A short cone trace through the SDF gives a soft shadow without ever touching the alpha-tested mesh. Particularly nice for trees because the SDF captures the canopy silhouette as a single solid blob and ignores the per-leaf detail.
• Lower-resolution cascades for foliage. Foliage shadows go into a half-resolution slice and get up-sampled with edge-aware filtering. The eye doesn't notice the resolution drop because the shadows are already soft.
• Alpha-to-coverage shadow maps with MSAA. On engines that still have MSAA in their shadow path, A2C gives smooth-edged foliage shadows without the full alpha test cost.
• Capsule shadows for the trunk and big branches, distance-field for the canopy, full alpha test only at the closest cascade. Different representations for different distances, blended in the lighting pass.
• WPO disable distance. Wind-driven World Position Offset is killed beyond a threshold so that cached shadow data stays valid across frames. UE's Virtual Shadow Maps lean heavily on this.

Deep dives:

• Epic, Distance Field Soft Shadows in Unreal Engine (the canonical UE reference for mesh DF shadows).
• Wright, Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, with Lumen's mesh-SDF integration for foliage).
• Epic, Virtual Shadow Maps (the modern UE5 shadow architecture, with the foliage-specific WPO disable and caching rules).
• Persson, Practical Cascaded Shadow Maps (the still-canonical CSM reference with notes on alpha-tested casters).

10. Wind, animation, and shadow caching

A subtle related problem: most foliage moves. Wind-driven vertex animation (World Position Offset in UE, equivalent in Frostbite and Decima) means the foliage geometry isn't stable from frame to frame, which breaks shadow caching and reprojection. Modern engines fight this in two ways:

• Cap WPO at distance. Beyond a threshold, the wind animation amplitude smoothly goes to zero. The eye can't see the sway that far away anyway, and the shadow caches stay valid.
• Bake the wind into the cluster bounds. Cluster bounding boxes are inflated by the maximum WPO offset so culling stays conservative without re-uploading per frame.
• Per-instance phase offsets. Identical trees use a per-instance random seed to offset the wind phase, so a forest doesn't sway in lockstep without paying for unique animation per tree.

This is the kind of detail that doesn't show up in technique lists but is the difference between a 3 ms forest and a 9 ms forest in practice.

Deep dives:

• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, with the Decima wind-animation pipeline and shadow caching).
• McAuley, Rendering the World of Far Cry 4 (GDC 2015, includes the wind-grid sampling for vegetation).
• Epic, Foliage and Virtual Shadow Maps (the UE5 community guidance on WPO disable distance and VSM caching).

11. The combined math

None of these tricks is a silver bullet. The interesting thing is what happens when you stack them:

• A naive masked-foliage pass on a dense forest scene measures 8-15x effective overdraw. Every visible pixel runs the leaf shader 8 to 15 times.
• Add a depth prepass and the main pass drops to ~1x overdraw, but the prepass itself still touches everything.
• Add front-to-back sorting and the prepass starts pruning itself.
• Add cluster-level GPU culling and the prepass touches only what could possibly be visible.
• Add LOD chains and imposters and the count of visible quads drops by an order of magnitude beyond 30 m.
• Add the visibility-buffer / Nanite path and the shading stage truly runs once per pixel even on dense overlap.
• Add distance-field shadows and the shadow cost stops scaling with the alpha test.

The headline result, repeated across the talks linked above: effective overdraw collapses from 8-15x to 1-2x, and total foliage frame cost falls by 4-6x in a dense forest scene. That's the entire reason modern open-world games can render forests at 60+ fps on consumer hardware.

12. What this means for the browser

Most of this stack maps cleanly onto WebGPU. We've already shipped GPU-driven culling, indirect dispatch, Hi-Z occlusion, and front-to-back sorted prepasses in the open-world browser engine. The depth prepass for masked geometry is straightforward: WebGPU supports depth-equal testing and discard in fragment shaders, with the same caveats about early-Z. Octahedral imposters port mechanically, the math is just sphere-to-octahedron unwrapping and atlas indexing.

The harder pieces are the modern ones. A visibility buffer in WebGPU means writing a 32-bit triangle ID into a render target and resolving materials in a fullscreen compute pass; the building blocks exist but the orchestration is involved. Mesh distance-field shadows want a 3D texture per asset and a short cone trace, both of which are in WebGPU's reach. Hashed alpha and dithered LODs are one shader function each.

The path forward for browser foliage is the same as for everything else in this stack: ship the cheap, robust pieces first (prepass, sorted instances, LODs, imposters, hashed alpha) and add the heavy machinery (visibility buffer, mesh-SDF shadows) on top. The browser hardware floor is finally high enough that there is no architectural reason a WebGPU forest shouldn't look and run like a console one. There are just engineering reasons, and engineering reasons are the kind we like.

Further reading across the whole stack

If you want one source that pulls all of this together, the SIGGRAPH "Advances in Real-Time Rendering in Games" archive (advances.realtimerendering.com) has the canonical foliage and GPU-driven-rendering talks going back to 2014. Adrian Courrèges' GPU profiling articles include frame-by-frame breakdowns of GTA V and Horizon Zero Dawn that show every pass discussed here in production order. For the alpha-test math specifically, Chris Wyman's research page has the hashed-alpha and stochastic-transparency papers with reference shaders. And the Real-Time Rendering, 4th edition chapters on transparency, sampling, and depth handling are still the textbook starting point.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 24 made the world persistent and gave its vegetation wind. This part is about the people in it again, but from the wardrobe side: can a creator pick a base body, swap clothing, choose a hairstyle, and play any animation, all on a free asset pack, with no rigging and no animation authoring? Building a custom rig is not the right thing to de-risk. The question worth answering is whether a CC0 pack can carry the whole load.

A pack that was built to fit together

Open Spike 50 in a new tab ↗ · View source

Quaternius ships four assets that line up almost suspiciously well: Universal Base Characters with male and female bodies plus eight hairstyles and two eyebrow sets, Modular Character Outfits split into body, arms, legs, and feet parts with accessories like pauldrons and a hood, and the Universal Animation Library packs one and two, 262 clips in total covering locomotion, combat, climbing, farming, fishing, idles, and social moves. Inspecting their glTFs revealed why they fit: every single mesh in all four packs is rigged to the same 65-joint UE5-style skeleton, the same joint names, the same bind poses, root through pelvis and spine to head, mirrored arms with fifteen finger joints per side, mirrored legs. No retargeting needed. This is the exact opposite of the three-skeleton retargeting problem from Spike 35, where a 213-bone face rig had to talk to a 65-bone Mixamo rig. Here all four packs were authored on the animation library's skeleton on purpose, and the bond is exact.

That turned the spike into a binding exercise rather than an animation-pipeline one. The base layer loads a body glTF, clones the scene with SkeletonUtils.clone so each character gets a fresh skeleton instance rather than feeding bone mutations back into the loader's cached scene, and caches that 65-bone skeleton as canonical along with the armature object that roots animation.

Rebinding a coat onto a body

The trick that makes the whole thing work is that you can't simply reparent an outfit's mesh into the scene, because it still references the bones from its own glTF, which sit in a different subtree. Each modular part, a peasant body or a ranger's legs, arrives as its own SkinnedMesh with its own clone of the same armature. The binding walks the source skeleton's bones in their original order, looks each one up by name in the canonical skeleton, and builds a new Skeleton from those rebound bones reusing the source's bind-inverse matrices, then calls SkinnedMesh.bind with the source's identity bind matrix. After binding, the mesh detaches from its source scene and parents directly under the character root. Because the bind matrix captures the world transform at bind time and the root sits at identity, the mesh's own world transform never affects the output and skinning happens entirely through the now-shared bones.

Hair and eyebrows are slots too, and they corrected a wrong assumption. The folder structure said "rigged to head bone," which suggested hair would be a static mesh parented to the head with a baked offset. It isn't. Every hair file is a SkinnedMesh weighted across all 65 joints, with the long hair's weights bleeding into the upper spine and neck so it drapes when the character looks down. So hair takes the same by-name rebinding path as any outfit part. The one special case is the outfit body slot: when it's attached, the base body mesh is hidden so the outfit doesn't clip through it, while arms, legs, feet, and accessories just stack because the pack authored them to coexist with the base body showing through wherever the clothing leaves skin exposed.

262 animations for free

Animation is almost anticlimactic once the skeleton is shared. The two library glbs load, their clips flatten into one named list, and the track names in those clips reference the exact joint names by bone.position, bone.quaternion, and bone.scale. An AnimationMixer rooted at the character's armature finds those bones by name and drives them directly, crossfading on switch. The viewer's right panel is a filterable list of all 262 clips with a source pill, so searching "fish" surfaces every fishing animation across both libraries. Standard three-point lighting with soft shadows, a polar grid underfoot, and ACES tone mapping keep the stylized base textures readable without crushing the dark bodysuit's shadows.

What this de-risks for the product is large. The avatar customization feature can ship on a CC0 pack with zero rigging work and zero animation authoring: drop in the four packs, wire a wardrobe UI, and you have roughly six outfits times eight hairstyles times two sexes times 262 animations of variation out of the box. The 65-joint skeleton is small enough that GPU skinning cost is negligible, and the batched-skinning work from Spike 45 already handles 200-plus avatars on a rig this size. CC0 carries no use restrictions, so commercial use on a paid creator platform is fine. The remaining open question is custom-uploaded outfits, which is a Phase 3 problem solved by retargeting at upload time onto this canonical skeleton, the inverse of Spike 35's runtime retargeting. The asset footprint is about 147 MB on disk as raw 2K PNGs and uncompressed animation glbs, which production would shrink to roughly 30 MB with KTX2 texture compression and a gltf-transform pass.

Technology referenced in this chapter

One canonical skeleton across a pack. Four Quaternius packs (base bodies, modular outfits, two animation libraries) are all rigged to an identical 65-joint UE5-style skeleton with the same joint names and bind poses, so combining them needs no retargeting. Cloning the base with SkeletonUtils.clone gives each character a fresh skeleton instance instead of mutating the loader's cached scene.

By-name skeleton rebinding. Each modular part ships its own SkinnedMesh referencing its own armature. Rebinding walks the source bones in order, maps each by name into the canonical skeleton, builds a new Skeleton reusing the source bind-inverses, and calls SkinnedMesh.bind with the identity bind matrix, then parents the mesh under the shared character root so skinning runs entirely through the shared bones. The outfit body slot hides the base body to avoid clipping; other slots stack.

Hair as a skinned slot. Hair is not a static head-bone attachment but a SkinnedMesh weighted across all 65 joints, with long hair weighted into the upper spine and neck so it drapes on look-down. It takes the same rebinding path as outfit parts.

Name-keyed animation retargeting for free. Animation Library clips reference joints by exact name, so an AnimationMixer rooted at the shared armature drives all 262 clips directly with crossfade, no per-clip retargeting. A CC0 license covers commercial use, and the small joint count keeps GPU skinning cheap enough to reuse the Spike 45 batched-skinning path. See GPU-driven LOD.

Part 25 of 29. Previous: Part 24 - Saving a world, and wind you can see Next: Part 26 - Water that holds up at every scale Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 23 put people in the world and gave them a voice. This part is about making the world remember what they did to it, and making it feel alive when nobody's touching it. Spike 47 is persistence: a creator sculpts terrain and places props, and those edits survive a reload, sync to every other peer, and arbitrate cleanly when two people edit at once. Spike 49 is wind: porting a stylized nature pack's vegetation shaders so trees, bushes, and grass move the way the artist intended, which turned into a fight with the shader compiler more than with the math.

A world that remembers

Open Spike 47 in a new tab ↗ · View source

The setup is a shared authoring session. Players walk a world, place props with a click, remove them with a right-click, and sculpt the ground by dragging a brush, raising and lowering the heightmap or carving volumetric caves through the SDF terrain that promotes a chunk to marching cubes. Everything they do persists in a Cloudflare WorldChunkDO, a server-authoritative Durable Object backed by its own SQLite storage. Clients don't write state directly. They send intent, the DO arbitrates and broadcasts the result, and the DO is the single source of truth, so a fresh joiner gets a snapshot and lands in exactly the same world everyone else sees.

Two persistence details earned their keep. Terrain isn't stored as an event log to be replayed on join; it's stored as per-chunk binary blobs that are the source of truth, uploaded on stroke-end, so a joiner loads the committed bytes directly instead of re-running thousands of brush samples. And those blobs live one storage key per chunk rather than one big row, because a single SDF chunk is 168 KB and the DO has a 2 MB per-row limit. A chunk index tracks which keys exist so the DO can rehydrate the whole map on wake. Identity is handled with two storages on the client: the player id lives in sessionStorage so two tabs are two distinct peers rather than one peer that overwrites itself in the DO's player map, while the display name lives in localStorage so a rename in one tab carries across all of them.

Making concurrent edits converge

The genuinely hard part of multiplayer authoring is what happens when two people edit overlapping ground in the same instant. The spike splits edits by their algebra. Additive operations, raise and lower on the heightmap and add and subtract on the SDF, are commutative: applying them in any order lands on the same result, so they ride an optimistic-stamp path where each client applies locally and ships the stamp, and the DO broadcasts it to everyone with no coordination. Order genuinely doesn't matter, so there's nothing to coordinate.

The order-dependent operations, smooth and flatten, were the interesting case. The first design gave them a region lock: a client requests a lock on pointer-down, the DO grants or denies it, the client buffers samples during the press, and on pointer-up the DO applies the whole stroke atomically. It works, but it's a separate protocol with its own lock TTL and grant/deny round-trip. The cleaner answer that replaced it is a precomputed delta: the originator runs the smooth or flatten brush locally, then ships the resulting list of per-cell deltas, and every peer just adds those deltas to their own cells without re-deriving anything. That turns an order-dependent operation into a commutative one by freezing its result at the source, so the whole edit system runs on one uniform commutative protocol with identical convergence and no locks at all. Prop locks survive for a different reason: per-record locking replaced owner-only deletion, so any peer can delete any prop unless someone has locked it, and only the locker can clear it. Undo and redo work by letting the client name a prop's id before placing it, so it knows the id ahead of the server echo and can reverse its own actions deterministically. Hibernating WebSockets keep an idle room free throughout, the same property that made the avatar relay in the previous part cheap.

Wind ported faithfully, then fought

Open Spike 49 in a new tab ↗ · View source

Spike 49 takes Quaternius's Stylized Nature MegaKit and ports its wind to our stack. The pack ships its source Godot shaders, four of them, and the right move was a faithful translation rather than a re-invention. Bark has an empty vertex function, so trunks are rigid; an earlier procedural-mask attempt had been making trunks wave, and the fix was simply to stop applying wind to bark at all. Leaves get a per-vertex chaotic sway from a triangular-pulse hash, masked by height so canopies move and the base stays planted. Base foliage gets a noise-modulated sin/cos sway in world space. Grass is base foliage plus a wind-line bobble, sampling a scrolling noise texture through a power curve so only the bright bands of the texture contribute, which produces the visible ripples that travel across a meadow. The dispatch follows the pack's own material-naming convention, so a material called Leaves_Birch routes to the leaves path and Grass_Common to the grass path, no guessing.

A surprise from the port is that the leaf color isn't in the texture. Quaternius authors leaf appearance entirely from a vertical gradient and a Fresnel rim: the albedo is a mix from an extra color at the canopy bottom to the leaf color at the top, keyed on height, with a subsurface-scattering tint added as emission scaled by a $(1-\mathbf{N}\cdot \mathbf{V}{)}^3$ Fresnel term. That's why a plain textured pass looked flat. The colors come from the gradient and the rim, not the painted map. The port reads a baked heightFactor vertex attribute instead of raw local Y, normalized per leaf group at load time from world-space Y, so the gradient and the wind mask both behave correctly no matter how the FBX import rotated each mesh's local axes. The Godot color constants are tagged sRGB and converted to linear before the shader sees them, so the port does the same conversion rather than feeding the bright sRGB numbers in as linear and washing the foliage out.

The recompile that ate the frame rate

The reason this shipped as an FBX baseline first, with the full wind material set aside in a .bak file, is a per-frame recompile bug that dropped the scene to about 1 fps. Layering custom TSL onto FBX-loaded materials was triggering Three.js to rebuild shader programs every frame, with needsUpdate effectively stuck on. The diagnostic discipline was to strip each foliage material back to a plain textured pass with no custom nodes and watch whether the recompile loop persisted. If it stopped, the custom graph was the culprit; if it continued, the cause was upstream in the FBX material setup or Three.js itself. The fix that let the real shaders come back was binding every per-material difference, leaf color, SSS color, strength, and blend, as uniforms so all leaf assets share one compiled program instead of the compiler emitting a fresh shader for every unique color combination and thrashing the compile queue.

Two more pieces are worth keeping. Grass renders as one InstancedMesh per source file, and its wind is computed in world space because the sin phases key off world position. But the displacement has to be applied in local space before the instance matrix runs, and WGSL has no inverse() to call. For an instance matrix of translation, a Y rotation, and a uniform scale, the inverse of the upper 3×3 is just its transpose divided by the scale squared, so the shader multiplies the world displacement by the transposed model matrix and divides by the squared length of the matrix's first column, recovering the scale without a square root. After the vertex transform re-applies the matrix, the motion lands in world space exactly as authored, independent of each tuft's rotation or scale. And each tuft runs a per-vertex GPU frustum cull: it projects the instance center to clip space, and if it falls outside the frustum with margin, it collapses every vertex to the local origin so all three vertices of each triangle coincide, the rasterizer drops the degenerate triangle, and no fragment, alpha-test, or shadow work happens for off-screen grass. That stacks on top of the coarse per-chunk bounding-sphere cull Three.js already does, built from float step rather than booleans so it multiplies straight into the position mix.

Technology referenced in this chapter

Server-authoritative world persistence. A WorldChunkDO Durable Object arbitrates prop placement and terrain edits, persists per-chunk binary blobs as the source of truth (so joiners load committed bytes instead of replaying an event log), and stores one storage key per chunk to stay under the DO's 2 MB per-row limit. Player id lives in sessionStorage so tabs are distinct peers; display name lives in localStorage so renames carry across tabs.

Commutative edit convergence. Additive terrain ops (raise/lower, SDF add/subtract) are commutative and ride an optimistic-stamp path with no coordination. Order-dependent ops (smooth, flatten) are made commutative by shipping precomputed per-cell deltas instead of acquiring a region lock, so the whole system converges under one uniform protocol with no locks. Per-record prop locks replace owner-only deletion, and client-named object ids enable deterministic undo/redo before the server echo arrives. See GPU-driven LOD.

Faithful shader porting from Godot to TSL. Quaternius's four source wind shaders translate line-for-line: rigid bark, height-masked leaf sway, world-space foliage sway, and grass with a scrolling wind-line bobble, dispatched by the pack's material-naming convention. Leaf color comes from a height gradient plus a Fresnel-driven SSS rim rather than the texture, and sRGB authoring constants are converted to linear so the look matches the reference renders.

Avoiding per-frame shader recompiles. Layering custom TSL on FBX materials can pin needsUpdate and rebuild programs every frame, collapsing to ~1 fps. Binding every per-material difference as a uniform lets all variants share one compiled program instead of emitting a fresh shader per unique parameter set. A plain-textured diagnostic pass isolates whether the custom graph or the upstream setup is the cause.

World-space wind on instanced foliage. Grass wind is computed in world space and transformed back to local with a hand-derived inverse (transpose over scale-squared) because WGSL has no inverse(). A per-vertex GPU frustum cull collapses off-screen tufts to a degenerate triangle so no fragment or shadow work runs, stacking on top of Three.js's per-chunk bounding-sphere cull.

Part 24 of 29. Previous: Part 23 - Fifty avatars and a voice in the room Next: Part 25 - One skeleton, every outfit Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 22 put a sky over the world. This part puts people in it. A third-person open world wants 50-plus characters visible at any moment, and it wants to hear the ones standing next to you. Spike 45 is the rendering side: getting that many animated avatars onto the GPU without melting the main thread. Spike 46 is the audio side: peer-to-peer voice that pans and attenuates with position, tuned to sound like a normal video call rather than a tech demo.

One draw call for fifty dancers

Open Spike 45 in a new tab ↗ · View source

The default Three.js path gives every character its own SkinnedMesh, its own AnimationMixer, its own bone-matrix upload, and its own draw call. At 50 avatars on the local Mac that was about 13 ms of pure JavaScript overhead per frame before the GPU did a single thing. The de-risking question for the whole multiplayer track was whether one batched-skinning architecture could get that under control and scale linearly with character count.

The answer is a split between where the animation is computed and where it's drawn. Three character classes share one FBX template. The local player is a normal Avatar, a full skeleton clone with its own mixer, the standard Three.js path, because there's only ever one of it. Every remote peer is a VirtualSkeleton: also a full clone with its own mixer running the same clips, but every SkinnedMesh node is stripped immediately after cloning so only the bones survive. It never enters the scene. Each frame, after the mixer updates and the matrices settle, it packs (bone.matrixWorld × boneInverse) for all 100 bones into a slot of a shared Float32Array. The BatchSkinnedRenderer then owns one InstancedMesh per geometry piece, all reading from a single StorageBufferAttribute of bone matrices sized maxInstances × numBones × mat4, which is 60 × 100 × 64 = 384 KB. A MeshStandardNodeMaterial with custom positionNode and normalNode reads four bone influences per vertex straight out of that storage buffer. The result is one storage upload and one draw call per geometry piece for the entire crowd, regardless of how many people are in it. Skinning lives in the vertex shader, and the per-avatar JavaScript cost drops to running a mixer and copying 100 matrices.

The HUD that measures this had to be rebuilt too. The old version flagged "over budget" when whole-frame GPU time crossed 3 ms, but the frame always includes the shadow map, the ground, and the local player's full skinned mesh, which together run 3 to 5 ms on real hardware no matter how many synthetic peers exist. The fix is a budget that calibrates itself: while no batched avatars are present, it captures the live GPU time as a baseline through a fast EMA, then freezes that baseline and grows the budget linearly at 0.06 ms per added avatar once synthetics appear. It reads PASS at idle on every machine and tightens proportionally as the crowd grows.

The bug was a face you couldn't see

First runs in Chrome showed silver shadows on the ground and no avatars at all, with a WGSL parse error: cannot index type 'f32' on a line trying to subscript object.nodeUniform2[i] where the uniform was declared as a scalar. The honest part of this story is that the first fix was wrong and worked anyway. The guess was that InstancedMesh's instance-matrix path was generating the bad code, and swapping in a StorageInstancedBufferAttribute made the error disappear in Chrome. But it disappeared because the new path emitted different shader code, not because it addressed the cause, which is the most dangerous kind of fix.

The real culprit was morph targets. The 3MIKE.fbx ships with blend-shape facial expressions, the cloned geometry inherits the morphAttributes, and Three.js's MorphNode.setup() declares morphTargetInfluences as a scalar float and then tries to .element(i) it inside a synthesized loop, which is exactly the scalar-subscript the compiler rejected. The fix is one line, clearing geometry.morphAttributes = {} on geometry that doesn't use morphs, so Three.js never injects the MorphNode at all. The accidental Chrome fix stayed in for a while and then bit back: on Safari, the storage-instanced path produced Vertex buffer is not big enough 256 times over, because Safari's WebGPU backend doesn't translate it cleanly. Reverting it was the right call, and the plain bone-matrix storage buffer, which is core WebGPU rather than a generated instance path, works fine everywhere. The lesson is the one worth carrying: when a fix works on one browser and you can't explain the mechanism, you've patched a symptom, so read the actual generated WGSL. A getCompilationInfo() shim added later in the spike turned Three.js's generic "module is not valid" into the real Tint error and paid for itself many times over.

A related framework-evasion trick sits next to it. Three.js detects the standard skinIndex and skinWeight attribute names and tries to inject its own SkinningNode, even on an InstancedMesh whose custom positionNode already does the skinning. Renaming those attributes to boneIndex and boneWeight hides them from the framework, and the custom TSL reads them under the new names.

A relay that forgets you between words

The first version synced peers over BroadcastChannel, a same-browser stand-in with the real wire format and cadence, and the protocol comment promised the swap to real transport would be one line. Cashing that promise meant an AvatarRoomDO, a 74-line Cloudflare Durable Object that doesn't even decode the 36-byte binary frame. It forwards each message as-is to every other peer in the room, because the sender's id is embedded in the frame and each receiver filters its own echo client-side. The relay has zero awareness of identity. Hibernating WebSockets make an idle room free: the DO drops out of memory between messages and the runtime restores the tagged sockets on the next packet. At 10 events per second per peer that's 36,000 DO requests per peer-hour, about half a cent, with egress free on Cloudflare and roughly 6 to 10 times cheaper than the equivalent AWS WebSocket shape.

The swap surfaced a state-machine bug worth keeping. A remote player kept walking after they'd stopped. The animation request guarded against this._state, the currently playing clip, instead of the last queued name, so when two network messages arrived in the same tick, a walk then an idle, the idle compared against a state that hadn't advanced yet and got silently dropped. The peer was stuck walking forever, because future idle packets were deduplicated upstream as unchanged. The fix is to always overwrite the pending name and let the transition helper short-circuit genuine same-state requests, which it already did. The class of bug is general: a dedup check against the wrong reference value quietly swallows the input that matters.

Safari needed two more guards. It opens the WebSocket faster than Chrome, so the first inbound peer message could arrive before the batch renderer finished constructing, dereferencing null; dropping messages while the renderer is absent is safe because peers re-broadcast every 100 ms. And 'gpu' in navigator returned true while requestAdapter() returned null, so Three.js silently fell back to WebGL2, where the storage-buffer skinning chain has no valid translation and spewed errors. Checking for a real adapter and asserting the backend is actually WebGPU turns a degraded render into a clear loading-screen message. There was even a WGSL dialect gap: Three.js emits the modern two-argument @interpolate(flat, either) that WebKit's compiler hasn't shipped, patched by rewriting the shader source on the way into createShaderModule to drop the second argument, which is free because flat interpolation carries the same value on every vertex regardless.

Voice that pans with the room

Open Spike 46 in a new tab ↗ · View source

Spike 46 is proximity voice: peer-to-peer WebRTC with HRTF spatial audio, scoped explicitly to match Google Meet and Microsoft Teams quality in a quiet-to-moderately-noisy room. A VoiceRoomDO handles signaling as a JSON relay, sending each new peer a roster, announcing joins and leaves, routing SDP and ICE to one specific peer by socket tag, and broadcasting position updates that drive the spatial panners. It stamps the sender id on every message so peers can't spoof each other, and the audio itself never touches the DO. One RTCPeerConnection per remote peer, with the lexicographically smaller peer id always making the offer so both sides agree on who initiates without a full perfect-negotiation implementation.

On the receive side each peer's audio runs through a PannerNode set to HRTF with inverse distance rolloff, and the AudioListener updates every frame from the local player's position and facing using forwardX = sin(facing), forwardZ = cos(facing), which matches the scene's atan2(wx, wz) facing convention. One Chrome quirk cost an hour: a MediaStream consumed only by Web Audio sometimes won't pull packets, so each stream also attaches to a hidden muted <audio> element to force the decoder to schedule. On the quality side, browsers default to roughly 32 kbps mono Opus, so the spike munges the fmtp line on every offer and answer to bump it to 128 kbps with in-band FEC enabled and DTX disabled, then calls setParameters with a high max bitrate to guarantee the encoder actually uses what the SDP advertises. FEC is the second-biggest audible win after the bitrate bump, recovering from packet loss without renegotiation.

Deleting your way to clean audio

The audio chain that shipped is much smaller than the one I started with, and shrinking it was the real lesson. The first version had a high-pass filter, a click limiter tuned to catch keyboard noise, a compressor, a noise gate, and a wet-dry crossfade, fronted by a floating panel with twelve-plus sliders. When the user reported audible keyboard clicks, the instinct was to tune the click limiter harder and drop the dry mix, a stack of bandaids. The structural answer was that once an ML denoiser is in the chain, the click limiter and the gate and most of the high-pass are all redundant, because RNNoise is trained on exactly keyboard and mouse and typing noise, and amplitude clipping is a strictly worse version of the same job. Production clients ship ML denoise, echo cancellation, automatic gain, and a soft compressor for level, and nothing else. So four stages came out, the slider panel came out, and the "choose your noise reduction" toggles came out, leaving one fixed pipeline.

Each surviving stage earns its place. Browser echo cancellation stays on because RNNoise doesn't do echo, and without it speaker-into-mic feedback is unbounded. Browser noise suppression goes off because stacking it on RNNoise produces artifacts on fricatives, so you pick one denoiser. Browser automatic gain stays on, because turning it off made the signal too quiet for the compressor to work with and Web Audio's DynamicsCompressorNode has no makeup-gain parameter to compensate; the browser's broad levelling and the spike's fast compressor operate on different timescales and coexist. RNNoise runs at 92 percent wet mixed with 8 percent dry, because it can over-suppress unvoiced consonants like s, sh, and f whose voice probability dips, and the small dry path preserves them at the cost of a little keystroke leak.

Two features round it out. Push-to-talk doesn't flip track.enabled, because that discards everything still in the pipeline buffers and chops the last syllable on key release. Instead a GainNode near the tail ramps with setTargetAtTime, fast attack so the first syllable survives and slow release so the last consonant drains, with the track left permanently enabled. And a five-second broadcast delay, requested as a radio-style feature, runs a bypass leg and a DelayNode leg crossfaded together, with a dump button that snaps the delayed output to silence and counts down on the HUD before audio resumes. Bundling the denoiser was its own small saga: the published RNNoise worklet uses bare-specifier imports that no CDN resolves, so the fix was a local esbuild bundle producing one self-contained 1.9 MB file with the WASM base64-inlined, committed to the repo and referenced by a URL relative to the module so it resolves under the dev server, the VitePress build, and the custom domain alike. If the worklet ever fails to load, the chain still produces audio through a plain high-pass and compressor, and the HUD shows the failure in red.

Technology referenced in this chapter

Batched GPU skinning for crowds. Remote avatars run a headless VirtualSkeleton (a full clone with the skinned meshes stripped, bones kept, its own mixer) that packs bone.matrixWorld × boneInverse for every bone into a shared StorageBufferAttribute. One InstancedMesh per geometry piece reads those matrices in a custom TSL positionNode/normalNode, so the entire crowd costs one storage upload and one draw call per piece, with per-avatar CPU work limited to a mixer update and a matrix copy. See GPU-driven LOD.

Reading the generated WGSL, not the symptom. A cannot index type 'f32' compile error traced to Three.js's MorphNode declaring morphTargetInfluences as a scalar and subscripting it, fixed by clearing morphAttributes on geometry that doesn't use morphs. A first fix that only changed which shader path was generated masked the cause and broke Safari later. Renaming skinIndex/skinWeight to boneIndex/boneWeight hides the attributes from Three.js's automatic SkinningNode injection so a custom skinning material owns the math.

Hibernating Durable Object relays. A pure-binary AvatarRoomDO forwards 36-byte frames to every other peer without decoding them, with sender identity embedded in the frame and self-echo filtered client-side. Hibernating WebSockets make an idle room free, and the shape costs about half a cent per peer-hour at 10 Hz, far below the equivalent managed-WebSocket pricing. A dedup guard that compared against the playing animation state rather than the last-queued one silently dropped stop messages and stuck remote players in a walk loop.

WebRTC proximity voice with HRTF. One RTCPeerConnection per peer with offer/answer roles decided by peer-id ordering, audio routed through a HRTF PannerNode with an AudioListener updated per frame from player facing, and Opus munged to 128 kbps with in-band FEC for resilience. A muted hidden <audio> element forces Chrome to pull packets from a Web-Audio-only stream.

Subtractive audio engineering. Matching Meet/Teams quality meant removing stages, not adding them: ML denoise plus echo cancellation plus automatic gain plus a soft compressor, with no gate and no click limiter, because an ML denoiser trained on keyboard noise makes amplitude clipping redundant. Push-to-talk ramps a tail GainNode with an asymmetric envelope instead of flipping the track so syllables aren't clipped, and the denoiser worklet ships as a single self-contained esbuild bundle to dodge bare-specifier import resolution.

Part 23 of 29. Previous: Part 22 - Clouds you can light, and culling that has to be fed Next: Part 24 - Saving a world, and wind you can see Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 21 was about a rendering technique that didn't pay off. This part has one that did, and one that needed a careful fix to work at all. Spike 43 is the sky: a physically based atmosphere and volumetric clouds, the foundation that makes a scene read as a place instead of a tech demo. Spike 44 is meshlet-style GPU culling, where the lesson was that the occlusion test is only as good as the occluders you feed it.

A sky from physics, not a gradient

Open Spike 43 in a new tab ↗ · View source

Almost every cinematic weather effect depends on two pieces of infrastructure: a physically based atmosphere, so the sky color and sun color follow time of day from physics rather than a hand-tuned gradient, and a volumetric cloud volume, so the sky has 3D structure instead of a baked cubemap. Spike 43 builds exactly that pair on the existing WebGPU and TSL stack, nothing more, because once those two exist the rest of the weather stack (fog, god rays, wet surfaces, snow) becomes a series of smaller known follow-ons.

The atmosphere is the Hillaire 2020 model, a set of lookup tables computed in WGSL compute shaders. A transmittance table integrates sun light through the Rayleigh, Mie, and ozone density profile and recomputes only when the sun moves. A sky-view table re-bakes every frame because it's cheap enough that gating it isn't worth the code, with a non-linear parameterization around the horizon to avoid banding. Multiple scattering uses an analytic fit instead of the proper table for now, and the sunsets read correctly, so the shortcut is hiding well. The clouds are a Schneider Nubis-style ray-march through a horizontal slab, with shape from a 128³ Perlin-Worley texture eroded by a 32³ Worley texture, both baked at boot in compute with no network fetch, lit with Beer's law extinction, a dual-lobe phase function, and a powder approximation. The key coupling is that the cloud's sun color samples the same transmittance table every step, so cloud lighting tracks sunset without a second tuning pass.

On an M1 the whole thing lands at 1.1 to 2.0 ms at half-resolution clouds, well under the 6 ms budget, using about 14 MB of GPU memory, running at over 100 FPS. The two thesis claims held up in practice. Sunset is the hero shot, the moment that makes the renderer feel cinematic, and it falls out of the physics without per-time-of-day tuning. And a happy accident: with the cloud slab parameterized between 800 m and 4000 m, distant clouds at the horizon read as dark mountain ridges from a low camera, which gives the world background terrain without anyone modeling background terrain.

One architecture note worth keeping. The natural shape is to paint the sky into the swap chain first, then let three.js draw geometry on top with autoClear = false. That does not survive the WebGPU renderer on r184, because the flag doesn't gate the color load op the way it does in WebGL, so three.js clobbers the sky every frame. The fix is to render three.js into an offscreen target and do the final composite (mix(skyCloud, scene, scene.alpha) then ACES then sRGB) in our own pass that owns the swap chain.

Culling that's only as good as its occluders

Open Spike 44 in a new tab ↗ · View source

Spike 44 benches four rendering modes against each other: plain forward, CPU cluster culling, GPU compute culling, and a visibility buffer with Hi-Z occlusion culling. The Hi-Z path is the interesting one, and it had a quiet bug: its HUD said occlusion was on, but the "Hi-Z killed" counter sat at exactly 0.0% forever. Frustum culling worked, so the cull shader's upstream was fine. The occlusion half was a no-op paying full cost.

A Hi-Z occlusion test projects a cluster's bounding box to screen, picks a depth-pyramid mip level so the screen rectangle is about 2×2 texels, samples the deepest occluder depth in that rectangle, and rejects the cluster if its closest point is still farther than that occluder. The depth pyramid is built every frame by seeding mip 0 from an opaque-depth pre-pass and max-reducing up. The opaque pre-pass deliberately includes only solid occluders, the ground and per-tree trunk proxies, because alpha-tested foliage would punch gaps that fool a max-reduce.

The bug was geometric, not logical. The trunk proxy was a 0.5 m by 4 m by 0.5 m box. At 30 m it projects to about 17 pixels on screen. But a typical 50 m grass cluster selects mip 5, where each texel covers 32 source pixels. A 17-pixel trunk doesn't fully cover a single mip-5 texel, so every texel touching the trunk also touches surrounding ground. The very first 2×2 max-reduce picks the larger depth value, which is the farther ground behind the trunk, and the trunk's depth gets erased on the first reduction. By mip 5 the pyramid holds ground depth almost everywhere, the cluster is never farther than the ground, and nothing is ever occluded.

The fix is to make the proxy big enough to dominate the texels it lands in, sizing it to the tree's silhouette rather than its wood. A roughly 2 m by 6 m by 2 m proxy is still smaller than the actual canopy, so leaves visible through gaps never get over-culled, but it's large enough to survive the max-reduce out to the distances that matter, and the occlusion counter immediately went non-zero. The takeaway generalizes to a rule for the production engine: anything trusted as a Hi-Z occluder has to be sized to its on-screen silhouette, because Hi-Z effectiveness in open foliage scenes is dominated by occluder coverage at the relevant mip, not by the elegance of the depth-test math. Grass-versus-grass occlusion can't fire anyway, since a blade sits at the same depth as the ground under it, so the real wins are trees occluding distant foliage and trees occluding trees.

Technology referenced in this chapter

Hillaire 2020 atmosphere LUTs. A transmittance table (sun light through the Rayleigh, Mie, and ozone profile) recomputed only on sun movement, plus a per-frame sky-view table with a non-linear horizon parameterization, give physically based sky and sun colors that track time of day with no hand-tuned gradient. An analytic multiple-scattering fit substitutes for the full table until an artifact forces the proper bake. Sunset falls out of the physics without per-time-of-day tuning.

Schneider Nubis volumetric clouds. A ray-march through a horizontal slab, shaped by a boot-baked 128³ Perlin-Worley texture eroded by a 32³ Worley texture, lit with Beer's law extinction, a dual-lobe phase, and a powder term. Sampling cloud sun color from the same transmittance table every step makes cloud lighting track sunrise and sunset for free. Half-resolution ray-march runs roughly 4× cheaper than full with no visible quality loss at typical distance, the standard production trade.

Compositing raw WebGPU with three.js on r184. Painting the sky into the swap chain and drawing three.js geometry over it with autoClear = false fails because the flag doesn't gate the color load op in the WebGPU backend. Render three.js into an offscreen RGBA16F target and do the final mix plus tone-map plus sRGB in a pass that owns the swap chain.

Hi-Z occlusion culling and occluder sizing. A depth pyramid built by max-reduce lets a GPU cull pass reject clusters whose nearest point is behind the deepest occluder in their screen rectangle. The test silently does nothing if occluders are too small to dominate a texel at the selected mip, because the first max-reduce replaces the occluder's depth with the farther background behind it. Occluders must be sized to their on-screen silhouette, not their physical core. See GPU-driven LOD.

Part 22 of 29. Previous: Part 21 - A faster renderer that wasn't faster Next: Part 23 - Fifty avatars and a voice in the room Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 20 faked surface depth on a flat quad. This part is about a render-architecture decision, and it's the spike where the textbook answer turned out to be wrong for our hardware. The question: for cinematic-density alpha-tested grass under a third-person camera, do we need a visibility buffer before pushing to 200-player density? The going advice is an emphatic yes. We built it, measured it, and the answer was no.

The technique everyone recommends

Open Spike 40 in a new tab ↗ · View source

A visibility buffer splits rendering into two passes. Pass 1 rasterizes geometry and writes only triangle and instance IDs into a compact integer target plus depth, doing no shading at all. Pass 2 is a fullscreen pass that reads the IDs at each covered pixel, refetches that triangle's vertices, reconstructs the interpolated attributes, and shades each visible pixel exactly once. The pitch is perfect overdraw rejection: the depth test runs against fragments that did no shading work, so the expensive material only runs on what you actually see.

The spike runs two paths on one canvas and one device so the only variable is where the shading lives. The forward path is a normal MeshStandardNodeMaterial through three.js. The vis-buffer path is a raw two-pass WebGPU pipeline running outside three.js, reading three.js's grass texture straight off the backend, writing (instanceId, triId) into an RG32Uint target in pass 1 and resolving lighting in pass 2. Both share one ground-truth lighting setup.

Two implementation notes worth keeping. WebGPU still has no portable primitive_index builtin in fragment shaders, so the trick is to bake a per-vertex triangle ID onto un-indexed geometry and read it flat-interpolated, which costs 3× the vertex count but is negligible on a 12-vertex grass card. And sharing the canvas with three.js's renderer is mostly a non-event as long as you never reconfigure the context or touch the canvas dimensions, both of which three.js owns. Timing the forward path was the fiddly part, since three.js exposes no hook to inject GPU timestamp queries inside its render pass; the workaround brackets its work with two no-op timestamp passes submitted before and after, which the GPU runs in submission order.

The numbers go the wrong way

On an M-series Mac at ~1080p, with cross-card grass blades over an 80 m field:

At 50,000 instances the vis-buffer path won by 25%, 4.13 ms against forward's 5.51 ms. At 100,000 it was break-even. At 200,000 instances forward won by 44%, 5.44 ms against the vis-buffer's 7.80 ms. The vis-buffer path gets relatively worse as density climbs, which is the exact opposite of the folklore that says it wins precisely when overdraw is heavy.

Why forward holds up

Apple Silicon GPUs are tile-based deferred renderers, and that changes the whole calculation. Forward shading on a TBDR has a hidden-surface-removal stage that runs before the fragment shader: the rasterizer collects every fragment mapping to a tile, sorts them by depth, and only the survivors (post-alpha-test) ever reach the fragment shader. So the forward path is already paying most of the visibility buffer's "shade once per pixel" promise, for free, inside the hardware. As blades crowd the screen, more fragments get rejected at HSR before any shading fires, and forward's effective per-pixel cost stays roughly flat instead of growing with overdraw.

Pass 1 of the vis-buffer path gets that same TBDR benefit. The trouble is all in pass 2. Pass 2 reads each pixel's instance matrix out of a buffer that, at 200,000 instances, is 12.8 MB, far larger than any GPU cache. Screen-adjacent pixels usually belong to different grass instances (the scatter is a jittered grid, so neighboring blades have arbitrary instance IDs), so every wave hitting that buffer misses cache divergently. That incoherent random access hides about 4 ms per frame on its own. Forward dodges it entirely because the instance matrix arrives with the vertex through the per-instance attribute path, so by the time the fragment shader runs the transformed vertex data is already in tile-local registers, no megabyte-scale random read required.

This is exactly the cost Nanite's material-classification pass exists to amortize: bin pixels by instance and dispatch sorted compute waves so each wave's reads are coherent. We don't have that. A back-of-envelope says sorting pixels by instance would drop that 4 ms to maybe 1.5 to 2 ms and push the crossover out to 400,000 to 500,000 instances. But that's stacking optimizations on an architecture that isn't winning here in the first place.

The honest conclusion, and the audit that earned it

For alpha-tested cross-card foliage on Apple Silicon WebGPU, the forward path with three.js's TSL pipeline is already at or below vis-buffer cost, and the vis-buffer plumbing buys nothing visible until well past 200,000 instances and only if you also add a sorting or binning pass. The practical call for the production engine is to keep the forward plus LOD plus imposter stack from the earlier spikes and not invest in vis-buffer infrastructure until either we target discrete NVIDIA or AMD GPUs as the dominant deployment (where overdraw cost is more linear) or we move to a meshlet architecture where the vis-buffer is the natural output anyway.

Because that result is counterintuitive, the conclusion is only worth anything if the comparison is fair, so the spike got a full audit pass. Several real bugs surfaced and got fixed: a blade-scale slider that silently desynced the two paths, half the forward blades rendering pitch-dark from anti-parallel normals (fixed with the canonical upward-normal foliage trick), and the vis-buffer reading about 2× too bright from a hand-picked Lambert factor instead of the energy-conserving 1/π, a hardcoded ambient term, and missing tone mapping. The fix copied three.js's exact ACES filmic curve into WGSL and reads the light colors and intensities off the actual scene lights each frame. The remaining known gap, missing direct specular in pass 2, biases the comparison toward the vis-buffer, meaning forward is doing strictly more per-pixel work and still winning at high density. That makes the headline conclusion conservative, not optimistic. The one caveat that stands: this is all M-series-specific, and the crossover may well invert on a discrete card, so it's worth re-running before committing the stack for non-Apple targets.

Technology referenced in this chapter

Visibility buffer rendering. Pass 1 rasterizes geometry and writes only triangle and instance IDs plus depth, doing no shading. Pass 2 is a fullscreen resolve that reads the IDs per covered pixel, refetches the source triangle, reconstructs perspective-correct barycentric attributes, and shades each visible pixel once. Since WebGPU lacks a portable fragment primitive_index, the triangle ID is baked as a flat-interpolated per-vertex attribute on un-indexed geometry.

TBDR hidden-surface removal versus deferred resolve. On a tile-based deferred GPU (Apple Silicon), forward shading already rejects occluded fragments before the fragment shader runs, so it captures most of the visibility buffer's shade-once benefit for free, and its per-pixel cost stays roughly flat as overdraw grows. A vis-buffer resolve pass instead pays for incoherent random access into a large per-instance buffer (12.8 MB at 200k instances), which dominates at high density unless pixels are sorted or binned by instance first, the way Nanite's material classification does.

Sharing a canvas with three.js's WebGPURenderer. Raw WebGPU command buffers interleave correctly with three.js submissions on the shared queue as long as you never call context.configure() again or write canvas.width/height, both of which the renderer owns. Forward-path GPU timing, which three.js doesn't expose a hook for, can be bracketed by two no-op timestamp render passes submitted around its render call, since the GPU runs command buffers in submission order.

Validating a counterintuitive benchmark. A surprising performance result is only as trustworthy as the fairness of the comparison. Auditing both paths to identical scene content and shading (matched ACES tone mapping, energy-conserving Lambert, lights read from the same objects, identical blade scale) is what turned "vis-buffer is slower" from a likely measurement artifact into a defensible conclusion, with the one remaining asymmetry biased in the conservative direction.

Part 21 of 29. Previous: Part 20 - Faking depth on a flat plane Next: Part 22 - Clouds you can fly through, and culling that pays off Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 19 used a flat quad to fake a whole tree at distance. This part uses a flat quad to fake depth up close: parallax occlusion mapping, the trick that makes a cobblestone road look like it has 5 cm of recessed grouting without spending a single extra vertex. The goal was to land it on the production stack (Three.js r184, WebGPU, TSL) so terrain detail materials can carry that depth illusion where it matters and pay flat-texture cost everywhere else.

Three ways to fake depth, side by side

Open Spike 39 in a new tab ↗ · View source

The spike lays three flat 5×5 m planes side by side, all the same material scaffold, differing only in the UV that feeds the samplers. Flat samples the texture straight, the reference baseline. Single-sample parallax shifts the UV once along the view direction by the height at that point, which is cheap and OK at low amplitude but swims at grazing angles. POM ray-marches in tangent space: step along the view ray, find the first layer where the ray passes below the heightfield, and refine the crossing. Tangent space stays simple because every test plane is axis-aligned, so the view direction packs into tangent space with a couple of sign flips instead of a full per-vertex TBN matrix. The texture set pulls live from the Polyhaven file API, the same path Part 17's model search used.

Two WebGPU walls, and a branchless ray-march

The textbook POM loop breaks out of the search on the first crossing. On r184 that doesn't work, for two separate reasons. If(...).and(...) compiled without errors but produced WGSL where the loop body never executed, so the post-loop refinement ran on garbage and the plane rendered nearly white. And Break() as a standalone node hadn't shipped to the r184 build at all, so even with a working If there was no way to express "stop on first crossing." Both trace back to known three.js issues around TSL control flow over-optimizing across If and Loop boundaries in this version range.

The rewrite is branchless. Every iteration unconditionally samples the texture, which keeps texture access in uniform control flow as the WGSL spec wants, then folds the new state in through a done flag held as a float. Once done flips to 1, the per-iteration mix calls degenerate to "keep state unchanged," which is the branchless equivalent of a break. The done flag is built with a step helper implemented as 0.5 + 0.5 × sign(x + ε) because boolean-to-float coercion has been spotty across the r18x line and sign() is universally safe. The cost is that every fragment runs all 64 iterations regardless of where it actually crosses, but that's the right trade at fragment scale: the runtime gates on max steps anyway, and a real GPU would speculate past a "real" break too. A clean fallback matters here, a final mix(baseUV, refined, done), so that at zero amplitude (the far end of the distance fade) no fragment crosses, done stays 0, and the POM material is bit-identical to flat. That's the whole point of the distance-LOD trick: collapse to flat cost where the effect is sub-pixel anyway.

The bug was a discipline failure, not a math failure

The branchless version ran but looked distorted, streaky horizontal artifacts at moderate amplitude and a subtly-wrong-but-not-crisp result at low amplitude. The fix came from a one-line prompt: go read the canonical reference. The LlamAcademy tutorial that inspired this is just a Unity ShaderGraph node, so the real implementation lives in Unity's PerPixelDisplacement.hlsl. Reading it line by line surfaced three semantic differences I'd unwittingly introduced: an off-by-one in the ray-height baseline (Unity does an initial advance before the loop, so my frame of reference was a whole step out of phase, landing crossings in the wrong layer about half the time), a sign convention on the max offset that the refinement step depends on, and a cumulative-offset versus cumulative-UV bookkeeping choice that made my refinement math work harder and tangled the sign.

The root cause wasn't any single error, it was mixing two references. I'd taken the LearnOpenGL POM tutorial as my guide, which uses similar but different sign conventions and a different refinement formula, and ended up in a mongrel state where two-thirds of the math matched one source and one-third matched the other. The rewrite is a near-verbatim port of Unity's HLSL into TSL, same variable names, same initial advance, same refinement, with the branchless done flag kept on top. The lesson is worth carrying: when you port a known-good shader from another stack, port it line-for-line with the same names first, then refactor for local style. Don't re-derive against a second reference mid-port.

A reference plane that can't lie

The side-by-side was missing the obvious thing: a real-geometry plane. Without it, "POM looks pretty good" is unfalsifiable. Pretty good compared to what? So the spike added a fourth plane, the same heightmap pushed through actual vertex positions. WebGPU has no hardware tessellation (it's simply not in the spec, cut for Metal compatibility), so the substitute is a densely subdivided plane (256×256 segments, 131,072 triangles) with vertex displacement in the vertex stage. The same amplitude uniform drives both POM and the geometry plane, so they fade together and the comparison stays apples-to-apples at every distance.

With ground truth on screen, the qualitative claims became measurable. At a 16° orbit looking down, POM and the tessellated plane agree on internal shading. At grazing angles they diverge exactly where they must: POM clamps to the geometry's perfectly straight rectangular edge, while the real mesh shows a bumpy horizon profile of actual peaks and valleys catching the light. So POM's edge "swimming" is now provably intrinsic to the algorithm, not an artifact of the texture or lighting. The two cost shapes are also clear: POM is fragment-bound (cost scales with covered pixels), the tessellated plane is vertex-bound (cost scales with mesh density regardless of coverage). For a terrain chunk, which already pays the vertex cost of a heightmap-driven plane, POM is the right answer for sub-mesh detail.

The reference plane also caught a subtle UX bug. The user noticed the surface appeared to sink as amplitude increased. That traced to Unity's convention treating the geometric plane as the top of the heightfield, so peaks anchor flush and everything else parallaxes downward, dragging the average surface below the flat baseline by (1 − mean_h) × amplitude. The fix re-centers the convention so h = 0.5 is the plane, peaks rise toward the camera and valleys recess. The algorithm runs exactly as Unity prescribes; the spike just post-processes the output by half an offset to match what "amplitude" should mean to a person dragging a slider.

One more thing the reference plane settled. A "Steps" slider seemed to do nothing, which read like a plumbing bug but wasn't. The three-iteration secant refinement after the linear search is so good (Tatarchuk's 2006 POM paper notes a 4-step search plus 3-step secant is visually indistinguishable from a 64-step search) that on a smooth heightmap every step count from 4 to 64 converges to the same sub-texel UV. The fix was a toggle, not a re-plumbing: turn the secant off and the step slider becomes the only control over crossing precision, so dropping to 4 visibly stair-steps the cobblestone and cranking to 64 smooths it back. The toggle is a 0/1 uniform that mixes every secant state update to a no-op when off, so toggling never rebuilds the material and never stutters.

Technology referenced in this chapter

Parallax occlusion mapping in TSL. POM ray-marches the view direction through a heightfield in tangent space, finds the first layer where the ray drops below the surface, and refines the crossing, producing recessed-mortar depth on a flat quad with no extra geometry. A final mix(baseUV, refined, done) makes the material bit-identical to flat when no fragment crosses, which is what lets distance-LOD amplitude attenuation collapse the cost to flat-texture cost at range. See terrain materials.

Branchless loops for WebGPU control flow. On Three.js r184, TSL If(...).and(...) can compile to WGSL whose loop body never runs, and standalone Break() isn't available. The portable pattern is an unconditional texture sample per iteration (keeping texture access in uniform control flow per the WGSL spec) plus a done flag held as a float that mixes each state update to a no-op once set. A step helper built from sign(x + ε) avoids unreliable boolean-to-float coercion. Cost is constant max iterations regardless of early-out point, the correct trade at fragment scale.

Verbatim shader porting. Porting a known-good shader from another engine should be line-for-line with the original's variable names first, refactor for local style second. Mixing two references (Unity's PerPixelDisplacement.hlsl and the LearnOpenGL tutorial) produced a mongrel with an off-by-one ray baseline, an inverted offset sign, and a refinement formula whose clamp masked out-of-range weights as spatial discontinuities. One canonical ground truth, not a re-derivation.

Vertex-displaced ground-truth reference. With no hardware tessellation in WebGPU, a densely subdivided plane (256² segments) displaced in the vertex stage stands in as real geometry to validate a fragment-stage fake. Driving both with the same amplitude uniform keeps the comparison honest across distance. POM is fragment-bound (scales with covered pixels) and the geometry plane is vertex-bound (scales with mesh density), so they diverge exactly at silhouette edges, proving POM's edge swim is intrinsic, not an artifact.

Part 20 of 29. Previous: Part 19 - The imposter that has to survive a forest Next: Part 21 - A faster renderer that wasn't faster Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 18 gave creators a brush that fills a hillside with trees. The catch is what those trees cost when there are tens of thousands of them on screen. A distant tree doesn't need 2,000 triangles to contribute four pixels. This part is the deepest LOD: the imposter, a flat quad wearing a photo of the tree, and the road from "one tree that looks right" to a million of them on the GPU.

A tree is two textures on a billboard

Open Spike 38 in a new tab ↗ · View source

An imposter pre-renders a prop from a grid of viewing angles into two texture atlases, one for color and one for world-space normals, then at runtime shows a single camera-facing quad sampling whichever tile matches the current view. The bake is two passes per tile: diffuse with an unlit material so no lighting bakes into the texture, and normals encoded as normalWorld × 0.5 + 0.5 with alpha forwarded from the source so the silhouette matches pixel-for-pixel. The runtime material is a full MeshStandardNodeMaterial, so the imposter still takes the scene's sun and IBL like any other surface. The win is the geometry: one quad instead of thousands of triangles, with the detail living in a 1 MB texture.

Pulling this into its own spike was itself a lesson. The imposter started as the deepest LOD inside spike 37's scatter system, and every iteration on the bake had to be tested through the full scatter pipeline, with bake correctness tangled up in instance-matrix migration and LOD swaps. Splitting it out to one prop, one quad, side-by-side with the original, dropped iteration time from minutes to seconds.

When the textbook answer is the wrong answer

The first implementation used octahedral encoding, the textbook mapping for packing sphere directions into a square. It passed numerical roundtrip tests, and yet the user kept screenshotting the imposter snapped to a tile that looked like the tree from slightly above instead of straight on. Six rounds of fixes followed (a per-quad view-direction uniform, a square bake aspect, debug materials, static billboarding) and every one was genuinely needed but none was the actual bug. The fix only came with "rethink it from scratch, KISS, no band-aids."

The rewrite threw out octahedral folding for plain azimuth by elevation: az = atan2(dir.x, dir.z), el = asin(dir.y), uv = (az/2π, el/π + ½). That's the whole encoding, no L1 normalize, no sign-of-zero corner cases. The reason it's better here isn't that it's more accurate (it samples a less uniform sphere), it's that the CPU cell-picker and the GPU shader use the same primitives, so they can't disagree at a boundary direction the way the octahedral pair quietly did. The atlas reads like a contact sheet: column is the angle around the prop, row is elevation, obvious at a glance in the overlay.

Even after that, the "looks from slightly above" complaint survived, and the cause was a quantization choice, not the encoding. With a 4×4 grid the row centers land at ±22.5° and ±67.5°, so there is no row at exactly 0° elevation. A viewer looking horizontally, the overwhelmingly common case, always falls into a row baked at a tilt. The fix is odd N: a 5×5 grid puts row centers at 0° and ±36° and ±72°, so the horizontal viewer gets a tile baked at exactly horizontal. The same family of "off-by-half-a-cell" mistake shows up again in the next part's parallax work, and the cure is the same question: does my discrete sample point actually land where I think it does for the canonical input?

Two more pieces mattered. The billboard has to be piecewise-static, not continuously facing the camera. The imposter is a flat photo taken from a specific bake direction, so the runtime quad's image plane must match that bake camera's plane, which means it holds orientation across the arc where one cell stays selected, then snaps at the boundary. And the budget should follow where players actually look: a later pass dropped the tilted top-down rows entirely in favor of 24 horizontal ring slots at 15° apart plus one straight-down tile, because trees are viewed from eye height roughly all the time.

The snap, and how blending erased it

Open Spike 42 in a new tab ↗ · View source

The piecewise-static billboard is invisible at distance and pops at close range, which is fine until you orbit. Spike 42 put four variants side by side (the original prop, the az/el 5×5 baseline, and two hemi-octahedral grids) to isolate the flicker and kill it. Two artifacts drive the snap. The cell pop happens because the fragment shader quantizes the view direction into one of 25 cells, so crossing a boundary swaps the sampled tile and re-aims the quad on the same frame. The pole degeneracy is the top-down view, where every azimuth collapses onto one point and the bridge between the ring and the top tile is the worst transition in the atlas.

Hemi-octahedral mapping fixes both. It maps the upper hemisphere onto the unit square continuously, so adjacent 3D directions land at adjacent UVs and there's no pole singularity and no need for a special top-down tile. The flicker cure is bilinear cell blending: instead of snapping to the nearest tile, find the 2×2 group of tiles bracketing the encoded direction and blend all four, 8 texture taps total (4 diffuse, 4 normal). Adjacent views now cross-fade instead of popping. The normal blend of two unit vectors isn't itself unit length, so it gets renormalized, which behaves like a slerp for the small angles between neighboring tiles. The cost is real (a 12×12 atlas is about 9 MB versus the az/el 1.6 MB, and the bake runs roughly 5× longer at 288 render-target passes) but the bake is a one-shot at load and the blend buys a pop-free result, which is what makes imposters usable while the camera is actually moving.

A million trees, one camera-position copy per frame

Open Spike 41 in a new tab ↗ · View source

Spike 38's runtime does one CPU lookAt per quad per frame, which is fine for one tree and fatal for a forest. At a million trees the per-frame matrix updates and instance-buffer upload would dominate everything. Spike 41 moves the entire per-frame pipeline onto the GPU. Each instance's center, yaw, and scale upload once at build time as instanced attributes and never change. The vertex shader builds the billboard basis from the world-space view direction camPos − center and expands a shared unit quad into world space. The fragment shader does the hemi-octahedral encode and the bilinear blend per pixel. The only per-frame CPU work for the whole forest is one Vector3.copy to update the camera-position uniform, which doesn't scale with tree count at all.

A nice piece of the math is that the per-instance yaw cancels out of the normal decode. The bake stores normals in the bake camera's frame, and because a yaw rotation about world up preserves +Y and the cross product is rotation-equivariant, the runtime basis built with a world-up reference already equals the rotated bake basis. So the shader decodes normals straight through the runtime basis varyings without ever touching the per-instance yaw. Placement uses a jittered grid rather than pure random scatter: partition the area into cells, drop one tree per cell at the center plus a bounded offset, which guarantees a minimum spacing (no two trees on top of each other) while still reading as a natural forest. One detail that's easy to miss is the bounding sphere. The geometry template is just a unit quad, so three.js would frustum-cull the whole forest the moment the camera looked away from the origin. Setting an explicit bounding sphere covering the full area plus a quad's margin keeps the corner trees from getting chopped at glancing angles.

Technology referenced in this chapter

Octahedral and azimuth-elevation imposter atlases. An imposter bakes a prop from a grid of view directions into a diffuse atlas and a world-space normal atlas, then renders a single billboard sampling the matching tile, replacing thousands of triangles with two textures. The textbook octahedral mapping gives uniform sphere coverage but is prone to CPU/GPU divergence at fold boundaries; a plain azimuth-by-elevation grid samples a less uniform sphere but guarantees the cell-picker and shader agree by construction. Use odd N so a row lands at exactly 0° elevation, and spend the tile budget on the horizontal ring since props are mostly viewed from eye height.

Piecewise-static billboard orientation. An imposter is a photo from a specific bake direction, so the runtime quad's image plane must match the bake camera's plane, not continuously face the runtime camera. The quad holds orientation across the arc where one cell stays selected, then snaps at the boundary, which is invisible at imposter distance and only pops up close where imposters aren't used.

Hemi-octahedral atlas with bilinear cell blend. Mapping the upper hemisphere onto the unit square continuously removes the pole singularity and the special top-down tile. The snap is killed by sampling the 2×2 tile group bracketing the encoded view direction and bilinear-blending all four tiles (8 taps), so adjacent views cross-fade. Blended normals are renormalized, approximating a slerp over the small inter-tile angle. Cost is a larger atlas (about 9 MB at 12×12) and a longer one-shot bake, traded for pop-free shading under camera motion.

GPU-driven instanced imposters. Per-instance center, yaw, and scale upload once as instanced attributes; the vertex shader builds the billboard basis and expands a shared unit quad, and the fragment shader does the encode and blend per pixel. Per-frame CPU cost for the whole forest is a single camera-position uniform copy, independent of instance count. Per-instance yaw cancels out of the normal decode because yaw about world up is preserved by the cross-product basis construction. An explicit forest-wide bounding sphere prevents three.js from frustum-culling the entire instanced mesh when the camera looks away from the unit-quad template's origin. See GPU-driven LOD.

Part 19 of 29. Previous: Part 18 - A scatter brush that feels AI-placed Next: Part 20 - Faking depth on a flat plane Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

A few weeks ago I wrote about the rendering techniques modern AAA games actually ship. One area I left thin was sky and weather, because it deserves its own list. Clouds, fog, rain, and snow are the systems that turn a terrain demo into a place. They also share more code than they look like they do. Volumetric clouds, ground fog, and god rays are all the same ray-march. Wet roads, snow accumulation, and footprint trails are all the same displacement plus PBR trick. Wind is one direction vector that everything in the scene reads from.

Here's a short, opinionated tour of how the bigger studios build this stuff in 2026, with the papers and engine talks behind each piece.

1. Physically based sky and atmosphere

Atmospheric scattering is the foundation. The sky color, the horizon haze, the way distant mountains turn blue, the orange of sunset, all come from light scattering through the air. Modern engines compute this from physics: Rayleigh scattering for the blue, Mie scattering for the haze around the sun, ozone absorption for the deep violet at the zenith.

The original 2008 Bruneton method baked everything into 4D lookup tables, which limited dynamic time-of-day and added LUT artifacts at low sun angles. Sébastien Hillaire's 2020 update, which is what UE5's Sky Atmosphere component ships, replaces the high-dimensional LUT with a few 2D textures and a multiple-scattering approximation that updates per frame. It runs from a phone to a high-end PC.

Deep dives:

• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, the modern standard, used in UE5).
• Bruneton and Neyret, Precomputed Atmospheric Scattering (EGSR 2008, the original LUT approach).
• Bruneton, Precomputed Atmospheric Scattering: a New Implementation (open-source reference, ozone and multi-planet support).
• Epic Games, Sky Atmosphere Component (UE5 docs).

2. Volumetric clouds with Perlin-Worley noise

The bedrock cloud technique in modern games started in Andrew Schneider's 2015 Horizon Zero Dawn talk. Clouds are not meshes. They are a 3D density function defined by layered noise: a low-frequency Perlin-Worley mix gives the overall cloud shape, and a higher-frequency Worley noise erodes the silhouette into wispy edges. A weather map (a 2D texture sampled by world XZ) controls coverage, cloud type, and precipitation per region. A height-based gradient blends between cumulus, stratus, and cirrus profiles by altitude.

The renderer marches a ray from the camera through the cloud volume, accumulating density and scattering. The "Nubis" iteration in 2017 added regional-scale authoring and animation, and the original PS4 implementation ran in about 2 ms for the entire sky. Most studios that ship volumetric clouds today still trace their lineage to this paper.

Deep dives:

• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, the canonical reference).
• Schneider, Nubis: Authoring Real-Time Volumetric Cloudscapes with the Decima Engine (SIGGRAPH 2017, the regional-scale follow-up).
• Hillaire, Physically Based Sky, Atmosphere and Cloud Rendering in Frostbite (SIGGRAPH 2016, the Frostbite version).
• Häggström, Real-time rendering of volumetric clouds (a clean, approachable thesis with full shader code).

3. Voxel clouds and Nubis³

The 2023 evolution of Nubis abandoned the 2.5D shape representation entirely in favor of true 3D voxels. Each voxel stores cloud density directly, which lets artists carve and animate cloud shapes the way they sculpt terrain. The cost of moving to a denser representation is paid back by ray-march acceleration with compressed signed distance fields and clever up-rezzing of sparse voxel data.

The result is the kind of cloudscape you can fly through without seeing the underlying tricks fall apart. It's overkill for most studios, but it's the direction the high end is moving.

Deep dives:

• Schneider, Nubis³: Methods (and madness) to model and render immersive real-time voxel-based clouds (SIGGRAPH 2023, the voxel-cloud talk).
• Schneider, Nubis, Evolved (SIGGRAPH 2022, the bridge between 2.5D and full 3D).
• Schneider, Real-time Volumetrics and VFX (Andrew's personal site, with course notes and breakdowns).

4. Layered cloud rendering and 2D backdrops

Not every studio can afford full-volume clouds, and not every camera angle needs them. A lot of games combine techniques: high-altitude cirrus rendered as a scrolling 2D layer, mid-altitude cumulus as volumetric rays, and low-altitude stratus as a thin participating-media slab. The horizon often gets a pre-baked sky cubemap that the volumetric pass blends into beyond a fade distance.

This layering is what keeps the cloud budget honest. A single cloud type at full quality can eat 4-6 ms; layering different qualities for different cloud altitudes can hold the same look at half the cost.

Deep dives:

• Vos, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (GDC 2016 video, the layering breakdown is in the second half).
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, RDR2's combined sky/clouds/volumetrics pipeline).
• Hillaire, Volumetric clouds and mega particles in REDengine 4 (GDC 2025, Cyberpunk 2077's cloud pipeline).

5. Volumetric fog with froxel grids

Fog is a 3D field, not a 2D screen effect. The standard modern approach is the froxel grid: a 3D texture aligned to the camera's view frustum, with each cell ("froxel" = frustum + voxel) storing density and lit color. A compute shader injects scattering from every light source into the grid, accumulates extinction along the view ray, and applies the result as a fullscreen pass.

This is what gives you light shafts through windows, colored fog around point lights, and visible volumes around explosions. It's also the underlying machinery for "atmospheric perspective" that fades distant objects into the air. The technique was introduced by Bart Wronski for Assassin's Creed 4 and standardized by Sébastien Hillaire in Frostbite.

Deep dives:

• Wronski, Volumetric Fog: Unified Compute Shader Based Solution to Atmospheric Scattering (SIGGRAPH 2014, the original froxel-grid paper).
• Hillaire, Physically Based and Unified Volumetric Rendering in Frostbite (SIGGRAPH 2015, the production-grade implementation).
• Kovalovs, Volumetric Effects of The Last of Us Part Two (SIGGRAPH 2020, with notes on temporal jitter and depth-correct compositing).
• Wright et al., Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, includes Lumen's interaction with volumetric fog).

6. God rays and crepuscular shafts

Visible rays of sunlight in misty air are not a separate effect. They fall out of the same fog system, as long as the fog density and the shadow map are both available to the same compute shader. When the shader injects light into a froxel, it samples the shadow map at that froxel's world position. Cells in shadow stay dark, cells in light pick up the sun color. March the camera ray through the result and the bright cells form continuous shafts.

Cheaper screen-space variants exist (radial blur from the sun position into the depth buffer) and are still the right pick on mobile or low-end hardware. They miss off-screen sun positions but cost almost nothing.

Deep dives:

• Mitchell, Volumetric Light Scattering as a Post-Process (GPU Gems 3, the screen-space radial-blur approach).
• Engelhardt and Dachsbacher, Epipolar Sampling for Shadows and Crepuscular Rays in Participating Media (I3D 2010, the more accurate GPU technique).
• Vos, Volumetric Light Effects in Killzone: Shadow Fall (SIGGRAPH 2014, the production version with shadow integration).

7. Lightning and stochastic weather events

Lightning is a one-frame effect with two parts: the bolt mesh, and the scene-wide tonemap and lighting response. The bolt itself is usually a procedural billboard mesh built from a recursive line-segment subdivision algorithm, jittered for chaos and tapered toward the ground. Some engines render it as a screen-space additive flash, others as a fully lit emissive geometry that casts light on the world via a one-frame point-light injection.

The interesting part is everything else: cloud bottoms light from below, the ground brightens for two frames, the auto-exposure metering takes a few frames to recover, and a delayed thunder cue plays based on distance. Done well, this turns a 16 ms flash into a five-second sequence that sells weather as something happening in the world, not just over it.

Deep dives:

• Reed and Wyvill, Visual Simulation of Lightning (SIGGRAPH 1994, the recursive bolt algorithm everybody still uses).
• Kim and Lin, Fast Animation of Lightning Using an Adaptive Mesh (IEEE TVCG 2007, more physically grounded).
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, RDR2's storm pipeline including lightning timing).

8. Rain particles, rain meshes, and screen-space drops

Falling rain in modern games is rarely just particles. The cheap and convincing solution is a small set of scrolling textures stretched across vertical or screen-aligned quads, lit by the same sun and sky probes as everything else. Closer to the camera, individual streak particles add detail. On the camera lens itself, droplet textures, sliding trails, and impact ripples sell the "you are inside the storm" feel.

Wind affects the rain direction. The same wind vector pushes the cloud weather map, bends grass, and tilts the rain quads. One scene-wide vector, dozens of consumers.

Deep dives:

• Tatarchuk, Artist-Directable Real-Time Rain Rendering in City Environments (EGSR 2006, the canonical layered-rain reference).
• Garg and Nayar, Photorealistic Rendering of Rain Streaks (SIGGRAPH 2006, the physics of light through raindrops).
• Wojciechowski, Rain in Cyberpunk 2077 (GDC 2021, a modern production walkthrough).

9. Wet surfaces, puddles, and ripples

Rain that doesn't change the ground looks fake immediately. Wet surfaces respond by darkening their albedo (water absorbs incoming light), flattening their normals (the water film smooths microsurface), and dropping their roughness (water is a near-perfect mirror at glancing angles). The shader change is small, the visual change is huge.

Puddles are mask-driven: a height-based or vertex-painted mask defines low spots that fill with water as a "wetness" parameter rises. Ripples are flipbook normal-map textures triggered by raindrop impacts. The really nice implementations build the wetness state up over time, so a long rainstorm slowly soaks the world and a brief shower only darkens the high spots.

Deep dives:

• Lagarde and de Rousiers, Moving Frostbite to Physically Based Rendering 3.0, section 5.5 (SIGGRAPH 2014, the canonical wet-surface PBR adjustments).
• Lagarde, Adopting a Physically Based Shading Model (the original blog series with the wet-PBR math).
• Cyanilux, Rain Effects Breakdown (an approachable Shader Graph walkthrough of puddles, ripples, and droplets).

10. Snow accumulation and deformation

Snow is the symmetrical problem to rain: the world has to remember it, not just receive it. The standard approach uses a top-down "snow accumulation" texture that builds up over time wherever the sky is visible (computed against a top-down depth or shadow map). The terrain shader samples this mask and blends in the snow material in shaded regions and snow-deep displacement in exposed areas.

Footprints and tire tracks are rendered into a sliding deformation map centered on the player. As the camera moves, old footprints scroll out and the texture wraps around. The terrain or snow shader samples this deformation map and pushes vertices down where it has been written. Battlefield 5's snow does this with hardware tessellation; cheaper approaches use a high-density terrain mesh with vertex displacement only.

Deep dives:

• Barré-Brisebois, Hands-on with Battlefield 5: how the small things matter (the production write-up of Frostbite snow).
• St-Amour, Real-time snow deformation (a thesis with full GPU implementation details).
• Andersson, Terrain Rendering in Frostbite Using Procedural Shader Splatting (the splat-system foundation that snow accumulation rides on top of).

11. Wind as a global system

Wind is not a particle effect. In production engines it's a single global vector (sometimes a low-resolution 3D field) that every dynamic system reads from in its vertex shader. Grass blades bend, tree branches sway, cloth flaps, leaves drift, rain tilts, smoke advects, cloud weather maps scroll. One uniform updated per frame, dozens of consumers.

The richer version is a "wind grid" that stores direction and strength sampled by world position, allowing for storms with localized gusts, sheltered valleys, and wakes behind buildings. Foliage also typically gets a per-vertex offset baked at authoring time so identical trees don't sway in lockstep. The result is a world that breathes at the same rate.

Deep dives:

• McAuley, Rendering the World of Far Cry 4 (GDC 2015, includes Far Cry 4's wind grid for vegetation).
• Habel and Wimmer, Realistic Real-Time Rendering of Landscapes Using Billboard Clouds (older, but the wind-on-vegetation math is unchanged).
• Frostbite, The Vegetation of Horizon Zero Dawn (SIGGRAPH 2017, with the wind-system architecture).

12. Sandstorms, blizzards, and dense weather

Severe weather is its own rendering category. A sandstorm is a thick, opaque, ground-aligned fog with a strong directional bias and aggressive distance fog. A blizzard adds a near-camera particle blast and reduced visibility. Volcanic ash and smoke are the same architecture with different colors.

The thing that sells these is not the particles, it's the coupling: the sun darkens, the sky tints, the post-process color grading shifts, ambient audio swaps, footstep sounds change, the player's voice gets muffled if they have one. The renderer is the messenger; the immersion comes from every system in the game responding at the same time.

Deep dives:

• Burley, The Real-Time Sky and Atmosphere of Uncharted: The Lost Legacy (GDC 2018, with notes on dense-weather composition).
• Khalifa, Atmospheric Weather Effects in Forza Horizon 5 (GDC 2022, modern open-world weather).
• Karis, The Technology Behind the Unreal Engine 5 "Lumen in the Land of Nanite" Demo (SIGGRAPH 2021, the cave dust scene's volumetric stack).

13. Time of day and dynamic skies

Real-time time of day is the multiplier that makes every other system in this list worth shipping. The sun direction and color update over a 24-minute or 24-hour cycle. The atmosphere LUT updates with the sun angle. The cloud lighting recomputes per frame. The shadow cascades repoint. The reflection probes refresh. The ambient color shifts. The post-process exposure adapts.

Doing this without visible artifacts is mostly a story of texture caching and temporal stability. Fast techniques precompute the sky at fixed sun angles and interpolate; slower ones recompute every frame. The Hillaire 2020 atmosphere model is fast enough to recompute, which is why UE5 ships it. The cloud weather map scrolls with wind, so coverage shifts naturally without anyone authoring keyframes.

Deep dives:

• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, with the dynamic time-of-day discussion).
• Pesce, Real-Time Sky Rendering: Techniques and Tradeoffs (Ray Tracing Gems II chapter, modern survey).
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, with the 24-hour pipeline).

14. The weather state machine

Underneath all of this is a tiny state machine. Most games ship somewhere between 4 and 12 weather states (clear, partly cloudy, overcast, light rain, heavy rain, thunderstorm, fog, snow, blizzard, sandstorm), each defined by a set of parameters: cloud coverage and type, wind speed and direction, precipitation type and intensity, ambient color tints, audio profile, post-process grade.

Transitions are linear interpolations between parameter sets over 30 to 120 seconds. The transition isn't a special case, it's just two states being lerped, with each rendering subsystem reading the current parameter values that frame. Weather can be scripted (cutscene needs a storm), seeded (deterministic per region per in-game day so that two players in the same world see the same weather), or fully authored on a region grid. The cleanest pipelines treat all three as different schedulers writing into the same parameter buffer.

Deep dives:

• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, with the weather-state pipeline).
• Khalifa, Atmospheric Weather Effects in Forza Horizon 5 (GDC 2022, with the parameter-blend approach).
• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, with weather-map-driven cloud evolution).

15. The cinematic moments

The whole stack exists for a few signature moments. Standing on a ridge as a storm front rolls in. Watching a sun shaft burn through a clearing in the canopy. Walking out of a cave into snow. Flying through a cumulus cloud and seeing the light on the inside.

These are the moments players take screenshots of. They're also the moments where every system above has to be working at the same time: cloud volumetrics, atmospheric scattering, fog with shadow integration, wet PBR, wind on the foliage, time-of-day color grading, and a transition between weather states all composing into one frame. Get any one of them wrong and the magic snaps.

What this means for the browser

Most of these techniques map cleanly onto WebGPU. We've shipped basic atmospheric fog, equirectangular skybox blending, and screen-space distance haze in the open-world browser engine. The harder pieces (full volumetric clouds, froxel grid fog, wet PBR with dynamic puddles, snow deformation maps) are the obvious next step now that the terrain pipeline is stable. Spike 24's per-fragment fog color sampling from the skybox is one piece of this puzzle. A compute-shader cloud raymarcher feeding into the same atmosphere LUT is the next.

The good news is that the browser hardware floor is now high enough. WebGPU compute, 3D textures, indirect dispatch, and timestamp queries all exist. The Hillaire 2020 atmosphere has been ported to WebGL multiple times. Schneider's Nubis has open-source reference implementations in GLSL that translate to WGSL with mechanical edits. There is no longer a rendering reason that a browser game can't have the same sky as a console one. There are just engineering reasons, and engineering reasons are the kind we like.

Further reading across the whole stack

If you want one source that pulls all of this together, the SIGGRAPH "Advances in Real-Time Rendering in Games" archive (advances.realtimerendering.com) has the canonical weather and atmosphere talks going back to 2014. For production tear-downs of how specific games render their sky and weather, Adrian Courrèges' GPU profiling articles include detailed frame-by-frame breakdowns of GTA V, Horizon Zero Dawn, and Doom Eternal. For the sky and atmosphere math specifically, scratchapixel.com's volume rendering chapter is the gentlest introduction, and Hillaire's open-source implementation repository is the production-quality reference.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

If you crack open the rendering pipeline of a 2026 AAA game, most of what you'll find traces back to a small set of techniques that ship across studios. The names change between engines, but the ideas are the same. Here's a short list of what's actually doing the work on screen, with a figure and a few deep technical references for each.

1. Physically based rendering (PBR)

Materials are described by albedo, roughness, metallic, normal, and ambient occlusion textures, and lit by energy-conserving shaders (Cook-Torrance specular, Lambertian or Disney diffuse). It's the baseline every modern AAA engine assumes. If a surface looks consistent under sunlight, lamp light, and a flashlight, PBR is why.

Deep dives:

• Burley, Physically-Based Shading at Disney (the original "Disney BRDF" course notes, SIGGRAPH 2012).
• Karis, Real Shading in Unreal Engine 4 (SIGGRAPH 2013, the canonical UE4 PBR talk).
• Lagarde and de Rousiers, Moving Frostbite to Physically Based Rendering 3.0 (SIGGRAPH 2014, full Frostbite pipeline).
• Real-Time Rendering, 4th edition, chapter 9 (the textbook reference).

2. Deferred and visibility-buffer shading

Geometry first writes attributes (normals, material IDs, depth) into a G-buffer or visibility buffer. Lighting runs as a fullscreen pass that reads those buffers and shades each pixel once. Visibility buffers (used by Nanite and similar) push this further by storing only triangle IDs and resolving material parameters per pixel later, which keeps overdraw cheap on dense geometry.

Deep dives:

• Engel, Deferred Shading (NVIDIA, the foundational talk).
• Burns and Hunt, The Visibility Buffer: A Cache-Friendly Approach to Deferred Shading (JCGT 2013, the original visibility buffer paper).
• Wihlidal, "Optimizing the Graphics Pipeline with Compute" (GDC 2016, Frostbite's compute-based deferred path).
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, includes the Nanite visibility buffer in detail).

3. Virtualized geometry (Nanite-style)

Meshes are pre-built into a hierarchy of clusters. At runtime the GPU streams and selects clusters at the resolution that matches each pixel, so you get sub-pixel-accurate detail without manual LODs. Unreal's Nanite is the most visible example. Other engines now ship their own variants. The practical result is film-quality assets in real time without LOD authoring.

Deep dives:

• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021).
• Brian Karis, Nanite GDC 2021 talk (an accessible video walkthrough).
• Liktor, Geometry Rendering Pipeline Architecture at Activision (cluster-based rendering, 2021).
• Schied et al., Spatiotemporal Variance-Guided Filtering (related cluster culling techniques).

4. Real-time ray tracing for shadows, reflections, and AO

Hardware ray tracing (DXR, Vulkan RT) traces shadow rays, mirror and glossy reflection rays, and ambient occlusion rays against a BVH built each frame. Even a few rays per pixel beat what screen-space techniques can do, especially for off-screen reflections and contact shadows. Most games use it surgically, not for everything.

Deep dives:

• Microsoft, DirectX Raytracing (DXR) Functional Spec (the API reference).
• Wyman, Introduction to DirectX Raytracing (the SIGGRAPH course notes, very approachable).
• Boksansky and Marrs, Ray Tracing Gems II, chapters 17-19 (free PDF, modern DXR techniques).
• Stachowiak, Stochastic Screen-Space Reflections (Frostbite, the bridge from SSR to RT).

5. Software ray tracing (Lumen-style)

Not every player has an RTX card, so engines also ship distance-field or surface-cache fallbacks. Unreal's Lumen, for instance, traces against signed distance fields and surface caches for cheap diffuse GI, and only escalates to hardware rays when needed. It's how AAA games hit "ray-traced look" on consoles.

Deep dives:

• Wright et al., Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, the Lumen paper).
• Epic Games, Lumen Technical Details (official engine docs).
• Wright, Radiance Caching for Real-Time Global Illumination (SIGGRAPH 2021).
• Wright, Lumen GDC 2022 talk (video version).

6. ReSTIR and reservoir sampling

For direct and indirect lighting with thousands of light sources, ReSTIR (Reservoir Spatio-Temporal Importance Resampling) reuses light samples across pixels and frames. It's how games like Cyberpunk 2077 with Path Tracing keep noise low at one or two rays per pixel. Expect to see it in more engines as path tracing becomes the high-end target.

Deep dives:

• Bitterli et al., Spatiotemporal Reservoir Resampling for Real-Time Ray Tracing with Dynamic Direct Lighting (SIGGRAPH 2020, the original ReSTIR paper).
• Ouyang et al., ReSTIR GI: Path Resampling for Real-Time Path Tracing (HPG 2021, indirect-illumination ReSTIR).
• Lin et al., Generalized Resampled Importance Sampling (SIGGRAPH 2022, the math foundations).
• NVIDIA, Cyberpunk 2077 Path Tracing Tech Deep Dive (engineering blog).

7. Volumetric clouds, fog, and atmosphere

Skies are ray-marched through 3D noise and density volumes. Atmosphere uses precomputed scattering tables (Bruneton-style) for sun and moon transitions. Fog is a froxel grid (think a 3D texture aligned to the view frustum) that captures local lighting. Together they give you "weather as a system" instead of a skybox.

Deep dives:

• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, the canonical clouds reference).
• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, the modern Bruneton successor used in UE5).
• Wronski, Volumetric Fog: Unified Compute Shader Based Solution to Atmospheric Scattering (SIGGRAPH 2014, Assassin's Creed 4 froxel fog).
• Hillaire, Physically Based and Unified Volumetric Rendering in Frostbite (SIGGRAPH 2015).

8. Cascaded shadow maps and virtual shadow maps

For sun shadows, cascaded shadow maps split the frustum into ranges and render each at appropriate resolution. Virtual shadow maps go further: a single huge shadow map is split into pages and only the pages visible from the camera get rendered. It's how AAA games keep crisp shadows near the player without a giant memory bill.

Deep dives:

• Dimitrov, Cascaded Shadow Maps (NVIDIA whitepaper, the standard reference).
• Microsoft, Common Techniques to Improve Shadow Depth Maps (DirectX docs).
• Wright, Virtual Shadow Maps in Fortnite Battle Royale Chapter 4 (SIGGRAPH 2023, the UE5 VSM talk).
• Epic Games, Virtual Shadow Maps documentation.

9. Screen-space effects (SSAO, SSR, SSGI, SSSSS)

Reading the depth and normal buffers cheaply gives you ambient occlusion (SSAO), reflections (SSR), one-bounce global illumination (SSGI), and subsurface scattering for skin (SSSSS). They miss off-screen detail, which is why ray tracing is taking over, but they're still everywhere as a fast baseline.

Deep dives:

• Mittring, Finding Next Gen: CryENGINE 2 (SIGGRAPH 2007, the original SSAO paper).
• McGuire et al., Scalable Ambient Obscurance (HPG 2012, modern SSAO).
• Stachowiak and Uludag, Stochastic Screen-Space Reflections (Frostbite, the SSR reference).
• Jimenez, Separable Subsurface Scattering (the technique used for skin in most AAA engines).
• Mara et al., Deep Screen Space (Activision, an SSGI lineage).

10. Temporal anti-aliasing and ML upscaling (DLSS, FSR, XeSS)

The frame is rendered at a lower internal resolution and reconstructed using motion vectors, depth, and history. ML-based upscalers (DLSS 3/4, FSR 3, XeSS) add frame generation on top, interpolating intermediate frames from optical flow. Most AAA titles now ship assuming an upscaler is on, which changes how you budget the rest of the frame.

Deep dives:

• Karis, High Quality Temporal Supersampling (SIGGRAPH 2014, the canonical TAA talk).
• Salvi, An Excursion in Temporal Supersampling (NVIDIA, on the path to DLSS).
• Edelsten, Truly Next-Gen: Adding Deep Learning to Games and Graphics (GDC 2019, DLSS architecture).
• AMD, FidelityFX Super Resolution 3 technical details and Intel, XeSS technical paper.

11. GPU-driven rendering and mesh shaders

Culling, LOD selection, and draw submission all run on the GPU. Mesh shaders replace the vertex/geometry/tessellation pipeline with a more flexible compute-style stage that emits meshlets. Combined with multi-draw indirect, this keeps the CPU out of the per-object hot loop entirely.

Deep dives:

• Haar and Aaltonen, GPU-Driven Rendering Pipelines (SIGGRAPH 2015, the foundational Assassin's Creed Unity talk).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite GPU-driven culling).
• Kubisch, Introduction to Turing Mesh Shaders (NVIDIA, the mesh shader primer).
• Pesce, A Whirlwind Tour of Mesh Shaders (and similar engineering blogs collected on Adrian Courrèges' RenderDoc tear-downs).

12. Hair, cloth, and skin rendering

Hair uses Marschner-style anisotropic shading with strand-based geometry (NVIDIA HairWorks, AMD TressFX, or engine-native systems). Cloth is simulated on the GPU with position-based dynamics and rendered with anisotropic specular. Skin uses screen-space subsurface scattering plus pre-integrated wrap lighting. These three are usually where you spot the budget gap between AAA and indie.

Deep dives:

• Marschner et al., Light Scattering from Human Hair Fibers (SIGGRAPH 2003, the foundational hair model).
• Chiang et al., A Practical and Controllable Hair and Fur Model for Production Path Tracing (Disney 2016, used widely in real-time approximations).
• Müller et al., Position Based Dynamics (the standard cloth simulation reference).
• Jimenez et al., Separable Subsurface Scattering and Real-Time Realistic Skin Translucency.

13. Decals, virtual texturing, and material layering

Surface variation comes from layered decals (bullet holes, dirt, blood, grime) projected onto the depth buffer, plus virtual textures that stream high-resolution detail just-in-time. Material layering blends multiple PBR sets per pixel using masks and triplanar projection, which is how a single rock looks like five rocks.

Deep dives:

• Pranckevičius, Deferred Decals and follow-ups (Aras' classic blog series).
• Mittring, The Technology Behind the "Unreal Engine 4 Elemental Demo" (SIGGRAPH 2012, includes virtual texturing details).
• van Waveren, id Tech 5 Challenges: From Texture Virtualization to Massive Parallelization (SIGGRAPH 2009, the MegaTexture talk).
• Williams, Material Layering in The Order: 1886 (GDC 2014, layered PBR materials).

14. Order-independent transparency

Hair, foliage, particles, and glass don't sort cleanly. AAA engines use techniques like weighted blended OIT, depth peeling, or per-pixel linked lists to render them correctly without a CPU sort step. It's quietly one of the most expensive parts of the frame on a foliage-heavy scene.

Deep dives:

• McGuire and Bavoil, Weighted Blended Order-Independent Transparency (JCGT 2013, the WBOIT paper).
• Bavoil and Myers, Order Independent Transparency with Dual Depth Peeling (NVIDIA whitepaper).
• Yang et al., Real-Time Concurrent Linked List Construction on the GPU (the per-pixel linked list reference).
• Wyman, Exploring and Expanding the Continuum of OIT Algorithms (HPG 2016, comparison survey).

15. Neural radiance caching and ML denoisers

The newest layer. NVIDIA's neural radiance cache learns indirect lighting per-scene and queries it instead of tracing more rays. ML denoisers (OptiX, Intel Open Image Denoise, custom in-house) clean up sparse ray-traced signals in milliseconds. Expect this category to grow fast over the next two years.

Deep dives:

• Müller et al., Real-Time Neural Radiance Caching for Path Tracing (SIGGRAPH 2021, the NRC paper).
• Schied et al., Spatiotemporal Variance-Guided Filtering: Real-Time Reconstruction for Path-Traced Global Illumination (HPG 2017, SVGF).
• Chaitanya et al., Interactive Reconstruction of Monte Carlo Image Sequences using a Recurrent Denoising Autoencoder (SIGGRAPH 2017, the first recurrent ML denoiser).
• Intel, Open Image Denoise documentation (open-source production denoiser).

What this means for the browser

We've shipped several of these techniques in WebGPU for our open-world browser engine. Cascaded shadow maps, GPU-driven instancing, triplanar PBR, screen-space fog, and clipmap-based virtualized terrain all run at 120 FPS in a tab. The rest (hardware ray tracing, mesh shaders, ML upscaling) is coming to the web as the WebGPU spec catches up. For deeper dives, see our guides on browser open-world tech and landscape generation.

Further reading across the whole stack

If you want to read one book, Real-Time Rendering, 4th edition is the standard reference covering most of the topics above. For ongoing research, the SIGGRAPH "Advances in Real-Time Rendering in Games" course archive (advances.realtimerendering.com) has free PDFs of the AAA-engine deep dives going back to 2006. For production tear-downs of how specific games render their frame, Adrian Courrèges' GPU profiling articles are required reading.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 17 gave the player a combat-grade animation set and a way to pull any CC0 model into the world. This part goes back to the creator's side. Spike 34's palette places one prop per click, which is fine for staging a hero object and useless for a forest. Spike 37 is the brush: drag across the terrain and trees fill in where trees belong.

"AI-placed" without an AI

Open Spike 37 in a new tab ↗ · View source

The question this spike answers is whether a purely heuristic brush feels intelligent enough to skip the LLM. The test of "AI-placed" is concrete: trees stay off cliffs, rocks tilt into the slope, beach pebbles stop at the waterline, all on the first stroke. We got there with slope and altitude predicates, weighted draws, and per-family spacing, and not a single model call.

The brush works on a 257×257 CPU heightmap with hand-tuned features so every preset has somewhere to land: northern mountains for the mixed-slope picks, an eastern cliff strip for scree, a southern coastal plain for beach and meadow, a lake bowl in the south-west. The terrain bakes vertex colors from an (altitude, slope) biome classifier, so before you paint a single tree you can see where a preset will fire. Five presets ship as flat data, each a list of picks like { category, weight, slopeMin, slopeMax, altMin, altMax, minSpacing, alignToSlope }. Cliff and Scree sets slopeMin: 0.3 so rocks only land on actual slopes and alignToSlope: true so each boulder's up vector follows the surface normal.

For each stroke the scatter engine samples densityPerM2 × area candidate points inside the brush disc, reads height and slope per candidate, filters the preset's picks to those whose predicates pass, weighted-draws one, then runs a spacing check against an in-radius spatial hash. The whole thing is deterministic: a seedable Mulberry32 RNG owns every draw, so (seed, brush events) reproduces any session exactly. On the boot terrain a Mixed Forest stroke on flat meadow placed 139 of 158 candidates in 5 ms, while the same preset on a cliff placed only 106 of 226 and the HUD reported 81 of those rejected by slope. That rejection breakdown is the whole UX: you can see why the cliff only took a few trees instead of guessing.

The point of keeping presets as flat data is that the LLM version, when it lands, is a JSON swap rather than a rewrite. paint({ preset }) doesn't care whether preset.picks came from a hand-tuned recipe or a worker that expanded "deciduous forest with mossy boulders" into weights. The engine never hardcodes a prop id either, so dropping in a different catalog needs no engine changes.

From 300 draw calls to 49

The first cut rendered each placement as a clone(true) of a multi-mesh group, which is fine at a few hundred props and a wall at the 2,500 cap, where draw calls climb into the thousands. We swapped to InstancedMesh before that hit, with one bucket per (propId, partIndex). Each bucket grows by doubling: allocate a bigger InstancedMesh, copy the live matrices, swap the scene parent, dispose the old attribute. Erase is a swap-remove, so removing one instance is O(1) regardless of bucket size. Determinism, spacing, and the rejection HUD all carry through unchanged because the swap lives entirely below the placement record.

A diagnostic on the MegaKit pack settled a real architecture question. A multi-primitive glTF mesh (trunk plus leaves) can reach three.js as either one mesh with an array material and geometry.groups, or as separate sibling meshes with one material each. The loader takes the second path for this pack: every part is a single-material mesh with empty groups. That's the better shape for scatter, because separate buckets per primitive let the trunk bucket grow independently from the leaf bucket if their counts diverge. Same draw-call count either way, better memory shape with the split. The measured win held up: a forest stroke that was ~300 draw calls became 49, and a full multi-stroke session reached 3,221 instances at 75 FPS in 51 draw calls, a cap the clone path could never reach before frame budget collapsed.

Distance LOD, and four bugs hiding in it

Instancing cut draw calls but every instance still drew its full triangle count, even the trees 90 m out contributing two pixels of leaf detail. So we baked three LOD levels per prop part with meshoptimizer (full, 50%, 15%), extended the bucket key to (propId, partIndex, lod), and added a move() that shuttles a placement between sibling buckets with no allocation. Distance bands are 0 to 30 m, 30 to 90 m, and beyond, with ±4 m of hysteresis around each boundary so a camera hovering near a band edge doesn't thrash a placement back and forth re-uploading its matrix every frame. Re-evaluation is capped at 4 Hz and gated on the camera actually having moved, so a still camera costs one squared-distance compare per frame.

That LOD path is where the instructive bugs lived. The first showed up as placements vanishing or duplicating as the camera orbited, worse as the scene filled up. The cause was a shared scratch matrix: move() read a placement's transform into the module-scoped _tmpMat, but the source bucket's swap-remove used that same _tmpMat for its own internal shuffle, clobbering the carried matrix before the destination wrote it. The bug only spared the case where the moved slot was already last in its bucket, roughly a 1/count chance, which is exactly the "rare flicker that gets worse as the scene grows" the playtest saw. Fix was a dedicated _carryMat reserved for move() alone. Stress-tested at 1,274 cumulative moves, the cluster stayed pixel-identical.

The second bug was subtler: every LOD transition felt smooth except the first one. Trees crossing into LOD1 visibly shifted shading even though their silhouette barely changed, while bigger triangle drops later in the ladder looked fine. The simplifier with LockBorder never moves or invents vertices, so surviving vertices keep their normals exactly, but we were calling computeVertexNormals() after every simplification anyway. LOD0 returns the original artist-authored normals untouched; LOD1 and up got three.js's generic face-average recompute. The 0-to-1 boundary was the only place in the ladder where the normal regime changed, so that's where the pop lived. Dropping the one defensive line fixed the shading and, as a bonus, cut per-prop bake time roughly in half because we stopped recomputing normals on four LODs per part.

Auditing what the simplifier produced surfaced a third win. Each LOD was an original.clone() with a fresh index, and BufferGeometry.clone() deep-copies every attribute, so five LODs held five independent copies of position, normal, UV, and color buffers whose values were bit-identical across all of them. We refactored to share attribute references and only own a private index buffer per LOD, dropping a typical tree part from 20 distinct attribute identities to 9 and uploading each vertex buffer to the GPU once. Two contracts come with aliased storage: don't mutate attribute data through any single LOD, and don't dispose() a single LOD geometry, since both would hit every sibling that shares the buffer.

The fourth bug had nothing to do with painting. Just waving the cursor over the terrain dropped the frame rate, with no button held. The pointermove handler raycast against the terrain mesh, a 131,072-triangle plane with no spatial structure, so three.js walked the entire index buffer per event at up to 1,000 events per second. We didn't need the mesh for that lookup at all, because the terrain is a parametric heightmap. An adaptive ray-march against sampleHeight (big strides high above the surface, a 0.4 m floor near it, then 12 bisections on the sign flip) costs roughly 8 to 30 samples per ray instead of 131,072 triangle tests, about three orders of magnitude cheaper, and hover holds the frame cap again.

The cost just moves; make sure it moves off the click

After swapping the spike to WebGPURenderer on three r184 (the production target), a DevTools profile showed the very first paint blocking for 265 ms, 79% of it inside the meshoptimizer WASM. The bake was real work, around 180 simplify calls for a cold preset, but it was running inside the click handler because preloadProps only fetched and parsed scenes, never triggered the LOD bake. The fix was to make preset selection do the full bake in the background: preloadProps now calls the part-resolution path, caches the in-flight promise so a fast click joins it instead of forking a duplicate, and memoizes the per-geometry preprocessing the simplifier was redoing four times per part. First paint dropped from 209 ms to 4 ms in the HUD. The WASM time didn't vanish, it just left the user's critical path and runs while they're looking at the terrain deciding where to paint.

That's the recurring lesson of this spike. Almost none of these fixes changed what the brush does. They changed when the cost lands: off the click, off the hover, off the boundary the camera is hovering near. A scatter tool that feels instant isn't doing less work, it's doing the work where the user isn't waiting on it.

Technology referenced in this chapter

Heuristic suitability scatter. A brush samples candidate points in a disc, reads (height, slope) per point from a CPU heightmap, filters a preset's picks by slope and altitude predicates, weighted-draws one, and rejects it if it violates per-family minimum spacing tracked in a spatial hash. Slope-aligned picks rotate their up vector to the surface normal. This produces placement that reads as intentional (trees off cliffs, rocks tilted into slopes, pebbles stopping at the waterline) with no learned weights, and keeps the preset as flat data so an LLM-generated pick list is a drop-in swap.

Deterministic placement under async loads. A seedable Mulberry32 RNG owns every draw, so (seed, brush events) reproduces a session exactly. RNG draws happen before any await, and spacing reservations are inserted into the spatial index before the glTF clone resolves, so concurrent candidates respect each other and async asset loading can't perturb the sequence.

Bucketed InstancedMesh with O(1) edits. One InstancedMesh per (propId, partIndex, lod), capacity doubled on demand by copying live matrices into a larger buffer. Erase and FIFO-evict are swap-remove with a back-reference array patching the moved instance's index, so a removal is O(1) regardless of bucket size. A diagnostic confirmed glTF parts arrive as single-material meshes, making one-bucket-per-primitive the active path and giving each primitive an independently growable bucket.

Distance LOD with hysteresis and shared attribute buffers. Three meshopt-simplified levels per part, selected by distance bands with ±4 m hysteresis so a camera near a boundary doesn't thrash, re-evaluated at a capped rate and gated on real camera motion. Because LockBorder simplification never moves vertices, all LODs share one set of position/normal/UV/color buffers and differ only in their private index buffer, cutting distinct GPU vertex buffers by roughly half. Skipping a defensive computeVertexNormals keeps artist normals identical across LODs and removes the only shading discontinuity in the ladder. See LOD and meshoptimizer.

Analytic heightmap raycast for high-frequency lookups. A pointermove-rate cursor lookup against a 131k-triangle plane mesh walks the whole index buffer per event. Replacing it with an adaptive ray-march against the analytic height function (large strides far from the surface, a small floor near it, bisection on the sign flip of $({\text{ray}}_y-{\text{terrain}}_y)$) costs tens of samples instead of tens of thousands of triangle tests, about three orders of magnitude cheaper, and a pre-allocated output vector keeps the hot path allocation-free.

Move work off the interaction's critical path. Expensive one-time work (meshopt LOD bakes, WGSL pipeline compiles) should run during idle gaps, not inside the click handler. Preloading the active preset's full bake on preset selection, caching the in-flight promise so a fast click joins rather than forks it, and memoizing per-geometry preprocessing dropped first-paint latency from 209 ms to 4 ms without doing any less total work.

Part 18 of 29. Previous: Part 17 - Animations that didn't need retargeting, and a live asset search Next: Part 19 - The imposter that has to survive a forest Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Part 16 gave us a world you can place objects in. This part gives the player something better to do in it: a combat-grade animation set, and a way to pull any of a thousand CC0 models into the world by typing a search.

262 clips, one skeleton, three retargeting fixes

Open Spike 35 in a new tab ↗ · View source

The player rig is a CC4-style 3MIKE skeleton with 213 bones, including an 80-plus-bone facial rig and full finger joints. The animation sources don't match it. The first cut retargeted hand-picked Mixamo combat clips, but the source pool was thin and locomotion was split awkwardly between Mixamo and a few Kimodo BVH idles. The real win came when we pivoted the source library to Quaternius's two Universal Animation Library packs, 262 clips total on one consistent UE5-style 65-bone mannequin: sword combos, bow archery, climbs, wallruns, dodges, hit reactions, emotes, and a much cleaner locomotion set.

That's a 65-bone source to a 213-bone target, with no shared bone names, T-pose orientations, or limb proportions. Every clip gets remapped in three steps: a bone-name map, a bind-pose alignment so both rigs share a reference orientation, and position-track scaling so the shorter source rig doesn't put the character knee-deep in the floor. Getting that right meant chasing a sequence of bugs that each taught something specific.

The character came out over-twisted, every shoulder and elbow rotated about 30° too far. The cause was a pose mismatch: the UAL source ships a true T-pose, CC4's bind is an A-pose, and the retargeter assumed both rigs sat in matching reference poses, so the A-to-T difference got added into every per-frame delta. The fix forces CC4's arm chain into a true T-pose to capture the bind, then retargets, so the deltas stay small.

Then the body stopped translating. Knockbacks recoiled the upper body but left the feet planted. UAL puts displacement on the root bone, not the pelvis, so reading pelvis position gave near-zero motion. The fix sums root.position and pelvis.position, scales the horizontal part, and writes a single hip-position track. While doing this we found vertical offsets were off by about 12%, because we'd used the global limb-proportion ratio for the Y axis when pelvis height needs the hip-to-floor ratio. Two ratios, two axes: $\text{verticalRatio}=|\text{targetHipY}/\text{sourceHipY}|$ for Y, the proportion ratio for the horizontal. Overshoot gone. And a stream of RL_BoneRoot.position NaN warnings traced to mapping UAL's root (at $Y=0$) onto a target bone whose position track gets normalized by dividing by its bind Y. Divide by zero, NaN, silently dropped track. The fix was to drop the root mapping entirely, since its translation already lives in the hip track.

The smallest fix was the most satisfying to watch. The character gripped the sword with limp bind-pose fingers because the bone map had no finger entries, and the retargeter only writes tracks for mapped bones. Adding 30 finger bones (five fingers, three segments, two hands, dropping UAL's fourth tip helper that doesn't deform) made the hand close on the grip and open on the release.

Proving 262 clips without watching 262 clips

You can't eyeball-verify a 262-clip library, so we built an offline trajectory parity test: a headless Node script that loads each pack, samples the source skeleton at 60Hz, runs the retargeting pipeline, and compares per-bone world positions and rotations against the source after scaling. Pelvis Y drift came in at 0.003 m max. The hands showed a constant 2.5° offset that first read as "fingers aren't tracking," but a constant offset is the bind delta between the flat UAL hand and CC4's slightly cupped bind, and it's invariant across the clip. Real animation errors show up as drift that varies frame to frame. Once that was clear, the test became a one-shot regression check: if a clip's drift stops holding that constant baseline, a recent change broke retargeting.

A side-by-side reference mannequin made the visual half of debugging decisive. Pressing backslash shows whichever source rig owns the current clip next to the player, so a "twisted shoulder" question becomes "is the twist in the source, or did retargeting add it?" Numerical tests catch regressions, the visual reference catches bind-pose mistakes the numbers don't surface, and together they retired the guessing game.

With the pipeline solid, switching the WASD/jump/swim baseline from Mixamo to UAL was a thin alias map: the FSM still speaks generic state names like idle and walk, resolved to UAL clip names at playback. Swimming needed per-clip rig offsets because the freestyle and tread-water poses anchor the pelvis at different anatomical heights, so we submerge the rig half a meter for active swimming and deeper for treading, blending between them at a smooth 5Hz.

Type a word, get a model

Open Spike 36 in a new tab ↗ · View source

Spike 34 ate a day hand-curating a CC0 pack. The long-term answer is a search box. Polyhaven publishes about 1,100 CC0 models behind a permissive JSON API and a deterministic CDN, and this spike wires the whole path (query, thumbnails, load, render) from a static page with no build step, in roughly 300 lines of vanilla JS plus three.js.

On boot it fetches the full catalog once, about 600 KB. Search is pure client-side scoring (name beats id beats category beats tag) with a 120 ms debounce, rendering the top 60 cards. Thumbnails lazy-load through an IntersectionObserver so typing doesn't fire 60 requests at once. The interesting piece is loading. Polyhaven's file endpoint exposes multi-file glTF, not GLB, with textures shared across resolutions and split into separate files, and it hands back an include map of relative path to absolute CDN URL. Rather than download and patch the JSON ourselves, we feed that map through LoadingManager.setURLModifier, which fires for every dependency the loader needs (the .bin, each texture) and resolves it through the CDN. One click, one apparent file. Both API and CDN set permissive CORS, verified with curl before any client code, so no proxy. PBR materials render correctly with RoomEnvironment and ACES tone mapping defaults with no per-asset fix-ups, and 1k textures keep a typical model at 2 to 5 MB instead of 20 to 40 MB at 4k.

A meshoptimizer WASM pass rounds it out with a non-destructive reducer: each mesh stashes a clone of its original geometry, and changing the ratio rebuilds an index buffer from that clone rather than simplifying cumulatively. Multi-material geometry simplifies per group and rebuilds geometry.groups so material slots don't collapse. An armchair goes from 5,626 triangles at full to 2,812 at half.

Technology referenced in this chapter

Skeleton retargeting with bind-pose alignment. Mapping animation from one skeleton to another with different bone names, proportions, and reference poses requires three corrections: a bone-name map, a bind-pose alignment so both rigs share a reference orientation (forcing the target's A-pose arm chain into the source's T-pose), and position-track scaling. A pose mismatch adds the A-to-T rotation into every per-frame delta, doubling joint rotation. Unmapped helper bones must be dropped, since a root bone at $Y=0$ triggers a silent divide-by-zero in position-track normalization.

Two scale ratios for one rig. Horizontal displacement uses the global limb-proportion ratio (overall skeleton size), but vertical pelvis offset uses the hip-to-floor ratio $|\text{targetHipY}/\text{sourceHipY}|$, because the leg-to-torso proportion differs between rigs. Using one ratio for both axes leaves climbs overshooting and recoveries sinking below the floor. UAL displacement also lives on the root bone, not the pelvis, so both must be summed into a single hip-position track to preserve motion across knockback, climb, and locomotion clips.

Offline trajectory parity testing. A headless script samples the source skeleton at 60Hz, runs the retargeting pipeline, and compares per-bone world transforms against the source. A constant per-frame offset is the harmless bind delta, while drift that varies frame to frame is a real error, so the test becomes a regression check that fires when a change drops or distorts a track. Per-pack GLB isolation (fresh load, freed before the next) avoids cache contention across the sweep.

LoadingManager.setURLModifier for CDN glTF graphs. When a CDN ships glTF as a relative-URI graph with an accompanying include map (relative path to absolute URL), setURLModifier resolves every dependency the loader requests through the CDN without rewriting the JSON. This collapses a multi-file, multi-resolution distribution into a single-click load. Disposing each prior model's geometry, materials, and texture maps before the next load prevents hundreds of MB of GPU memory accumulating across a browsing session.

Non-destructive mesh simplification. Storing a clone of each mesh's original geometry and rebuilding only the index buffer per simplification ratio keeps changes fast and avoids cumulative damage from repeated simplification. Running per geometry.groups slice and reconstructing the groups preserves multi-material assignments. See LOD and meshoptimizer for how this feeds distance-based LOD.

Part 17 of 29. Previous: Part 16 - Structure for a world that keeps growing Next: Part 18 - A scatter brush that feels AI-placed Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Mariana Muntean, CEO of Cinevva

The most common thing strangers say about Cinevva is that it's an AI wrapper. They land on the homepage, see a single input box that reads "Describe your game", and decide they've understood the product. They've understood the front door. The product is everything you don't see when you type that sentence, plus, as of this week, an open world your players walk into to find your game in the first place.

Behind that input is a full game engine, an orchestrator with 26 typed tools, a fleet of generative models, an aggregated asset search across eleven providers, a live game iframe the agent can read and write to, and a storefront where the same agent ships your finished game as a swipeable gameplay reel. None of that is exotic. All of it is plumbing. The interesting work was deciding what to wire to what.

This post walks through the machine top to bottom. It's the explanation we give technical investors and the explanation we give developers thinking about contributing. They want the same answer.

1. The prompt is the surface, not the system

The first design decision was hiding everything until the user has skin in the game. The homepage has one job, which is to take a sentence and turn it into a project. We split the experience into a public side (the prompt, the showcases, the storefront feed) and a creator side (the IDE, the asset tools, the publish flow) so that the people who just want to play don't have to look at the cockpit.

That's why the placeholder rotates through things like "Make a snake game with neon graphics" and "Top-down zombie shooter". They aren't tutorials. They're a permission slip. The user sees that "weird arcade idea" is a legal input.

The moment you submit, three things happen. The system creates a fresh game project with a stable ID. It seeds an empty file tree (index.html, game.js, style.css, assets/, GDD.md). And it routes your sentence into the orchestrator with a project context window that points at those empty files. From here on you're talking to an agent that has hands.

2. Behind the input, a full browser IDE

The creator workspace is a three-panel IDE that runs entirely in the browser. File tree on the left, code editor in the middle, live game iframe on the right, and a chat input running along the bottom. We picked this layout on purpose. People who already write code recognize it instantly. People who don't can ignore the middle panel and only ever talk to the chat.

The file tree isn't a metaphor. Every project really is a small static site of HTML, JS, CSS, generated images, GLB models, and audio files, served straight from R2 through a Cloudflare Worker. There's no build step. The reason matters. It means the agent can read and write the files you'd actually ship, and it means the same artifact runs in the iframe, on a phone wrapped in Capacitor, on Steam wrapped in Tauri, and inside Discord as an Embedded Activity. One filesystem, six distribution targets.

Every game we generate is required to expose two functions on window. getGameState() returns a plain object describing the running game (player position, score, lives, enemies, timers). setGameState(patch) applies a partial update back to the live game. That tiny API is the contract that lets the agent inspect and modify a running game without reloading it. We'll come back to why in section 6.

3. The orchestrator, where the actual engine lives

The piece people miss when they call this "an AI wrapper" is that the AI doesn't write code so much as it conducts a small orchestra. The orchestrator is a tool-calling loop running against a frontier model, with a system prompt that's about a thousand lines long and a typed tool surface of 26 functions. The tool definitions are the engine. The model is the conductor.

The 26 tools fall into five families. Filesystem tools (list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files) let the agent treat your game like any other codebase. Project tools (create_new_game, list_games, open_game, ask_user, game_ready) handle the lifecycle of a project and the handoff back to the human. Generative tools (generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles) call out to specialized models that we'll cover next. Knowledge tools (search_fonts, list_library_docs, search_library_docs, list_generations) give the agent reliable, indexed sources of truth instead of hallucinated APIs. And runtime tools (read_console_logs, execute_js) let the agent see and touch the live game.

A typical first turn looks something like this. The user types "Make a neon space shooter". The model emits a write_files call with GDD.md describing the design, then write_files again with index.html, game.js, and style.css. It calls generate_music with prompt="synthwave space shooter, 120 BPM, driving bassline" which kicks off a job against ElevenLabs Music and returns an MP3 URL inside R2. It calls generate_skybox with a Blockade Labs model 3 style for the starfield. It calls game_ready(title, message) to flip the iframe to the new build, and finally read_console_logs to confirm the game booted without errors. If it sees a stack trace, it loops back to edit_files and fixes it before the user reports anything.

The interesting property of this design is that the system prompt and the tool schemas are the only thing that's product-specific. Swap the model and everything still works. We've migrated between three frontier models in the last year without changing the surface, because the surface is ours.

4. The asset side: a model fan-out

The agent doesn't generate images, music, sound, or 3D. It calls specialists. The asset side of Cinevva is a fan-out across best-in-class models, glued together so that the output of one is a valid input to the next.

For images and sprites, generate_image calls Flux Pro 1.1 with a width and height that's always a multiple of 32 and an output format that flips to PNG when the prompt asks for transparency. For full songs the agent calls ElevenLabs Music with a stylistic prompt and a duration in seconds. For one-off effects, ElevenLabs SFX produces a clip from text like "laser gun firing, sci-fi blaster" in five to fifteen seconds. For 360 degree environments, generate_skybox calls Blockade Labs with one of about ninety styles, defaulting to model 3 Digital Painting. For 3D characters, rig_model sends a GLB to Tripo to skin and rig as a biped, quadruped, hexapod, octopod, serpentine, or aquatic creature, then apply_animation plays back any of fifteen presets (idle, walk, run, jump, climb, dive, slash, shoot, hurt, fall, turn, plus the non-biped marches).

Each one of these is a job, not a sync call. They take seconds to minutes. The orchestrator launches them, returns immediately with a jobId, and a separate channel pipes the result back into the conversation when the asset is ready. That changes the feel completely. The agent can keep building game logic while a 3D model finishes rigging in the background. The user never has to wait on a single critical path.

The artifacts all land in the same place. R2, behind cdn.cinevva.com, addressable as plain URLs. Which means the agent's next write_files call can simply embed <audio src="https://cdn.cinevva.com/audio/abc.mp3"> and the game just works. No SDK, no asset bundler, no manifest.

5. Asset search across eleven providers

Generation is great when you need something specific. Search is faster when something already exists. The Asset Library is a federated search across eleven free and licensed providers, returned in a single ranked feed.

The provider registry sits in the worker and runs each query in parallel against PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, the Smithsonian 3D collection, TurboSquid, Synty, and Jamendo. Each provider implements a common interface (search, getMetadata, isBrowsable, getSupportedTypes), so adding a new one is a single TypeScript file. The aggregation layer handles cursor-based pagination across providers that paginate differently, deduplicates licenses, normalizes asset types into a common taxonomy (model, texture, audio, hdri, sprite), and tags each asset with its license so the agent never picks something it can't redistribute.

When ChatGPT recommended this tool last quarter as one of the best free asset finders for game devs, we went and read the recommendation. It was right about the part that matters. The point isn't that we have a search bar over a single library. The point is that an indie developer searching for "stone wall texture" gets results from PolyHaven and AmbientCG side by side with Kenney's stylized version and a photogrammetry option from Smithsonian, with one query, with consistent license metadata. The agent can hit the same endpoint and pick assets the same way a human does.

This is the part of the engine that often gets undersold. Most game-AI demos generate everything from scratch and end up with a uniform, glossy, slightly uncanny look. The interesting games on Cinevva mix generated assets with real CC0 photogrammetry from Smithsonian and a hand-made low-poly tree from Quaternius. The orchestrator can do that in one turn.

6. The agent plays the game

This is the part that surprises most engineers when we show it. The agent doesn't just write code into files. It runs the game in a sandboxed iframe, reads its console, takes screenshots layered for UI versus 3D scene, and executes JavaScript inside the live runtime to inspect or change state.

read_console_logs returns the last fifty lines of console.log, console.warn, console.error, and uncaught exceptions from the iframe. After every game_ready call, the agent is required by the system prompt to call read_console_logs and fix any errors before handing back to the user. That single rule eliminates most of the "the AI said it was done but the screen is black" failures that other tools have.

execute_js is the more powerful one. It runs arbitrary JavaScript inside the game's global scope. Because every game is required to implement getGameState and setGameState, the agent can run JSON.stringify(getGameState()) to read the entire state of the running game, then setGameState({player: {x: 500, y: 100}}) to teleport the player, setGameState({lives: 99}) to grant invincibility, or setGameState({level: 3}) to skip ahead. It can also poke at lower levels, like scene.children.map(c => c.type) to inspect the Three.js scene graph or document.querySelectorAll('canvas').length to confirm the renderer mounted.

You can see why this matters. When a user says "the player gets stuck in the wall on level two", the agent doesn't have to guess. It opens level two, runs getGameState(), examines collision data, runs an execute_js patch to test a fix, and only then writes the fix to disk. It debugs the way you debug. We treat the iframe as a peer, not a target.

7. Library docs, the boring source of truth

We index the official documentation for the libraries games actually use (Three.js, Tone.js, Cannon, and growing) into a structured, searchable JSON store. The agent reaches for search_library_docs("threejs", "Mesh") before it reaches for the open web. It's faster, it's versioned, and it never hallucinates a method that was renamed two minor releases ago.

This isn't glamorous. It's the difference between an AI that produces working code and an AI that produces convincing-looking code that crashes at line forty. Most of the visible quality of Cinevva-built games comes from this one decision.

8. From playable to discoverable: reels and the storefront

A game that nobody plays is a private hobby. The hardest unsolved problem in indie development isn't building games anymore. It's distribution. So the engine doesn't stop at "playable". It stops at "in front of players".

Every project on Cinevva carries a stable share URL like play.cinevva.com/{game-id} that opens the latest build of the game in a full-page iframe with a tiny overlay for likes and shares. When the agent calls game_ready, it doesn't only flip the in-IDE preview. It also offers to publish a 15-second gameplay reel to the Cinevva storefront. The reel is an actual recording of the game being played, captured directly from the iframe (we ship a small recorder script that the agent injects into the game runtime), so what the viewer scrolls past is real gameplay, not a marketing edit.

That changes the loop a developer lives in. The old loop was code, build, package, upload, write a Steam page, fight an algorithm, watch a wishlist counter. The new loop is type a sentence, watch the agent build, hit publish, watch your game appear in the same swipe feed alongside everything else. Discovery happens in the same product where creation happens, on the same URL, with the same login.

For dev community readers, this is the part to inspect. Distribution has always been the moat that game engines didn't ship with. Unity ships an editor, you ship the game on Steam. Unreal ships an editor, you ship on the Epic Store. Cinevva ships both halves. The engine and the storefront talk to each other through the same orchestrator that built the game.

9. Top Performers: the discovery flywheel

The reels feed is one half of the flywheel. The Top Performers chart is the other. It ranks games by trending, recent, and all-time top, weighted by completion rate (did the player finish a session) rather than raw clicks. Completion is harder to game than installs. A game that holds attention for sixty seconds beats a game that gets opened and closed.

Every signal feeds back into the orchestrator's next turn. When the agent says "let's add a power-up", it's not pulling from a fixed pattern library. It's pulling from a model that has watched what mechanics actually retain players on Cinevva this month. The flywheel isn't a chart at the bottom of the page. It's the training signal for the whole engine.

For investors, this is the data moat. We don't just have generated games. We have generated games with real session-level engagement metrics, attached to the prompts that produced them, attached to the asset choices the agent made, attached to the players who liked them. Every loop tightens the next one.

10. The engine becomes a game

Here's the part I've been hinting at on social for months. Everything in sections 1 through 9 describes a system that builds games. The harder thing to describe, until you see it, is what happens when the system itself becomes a place.

Game creation is hard work, even with everything we've shipped. If you've never made a game before, you're suddenly responsible for the plot, the characters, the world, the mechanics, who does what and when, how the light behaves, how the special effects layer on, the music, the sound effects, the camera moves. It's a lot. And on top of all that you want the result to feel like yours, not like a template someone else's tool spat out. The prompt and the orchestrator do most of the mechanical work for you. What they can't do alone is give your finished thing a stage to stand on with other people watching.

So we built the stage. For most of this year Oleg and the engine team have been publishing the work in a 14-part series about putting an open world in the browser. Sculpted terrain you can carve in real time. Biomes that paint themselves rock or grass based on slope and altitude. 80,000 grass blades that bend in the wind on top of compute-generated terrain. A character that walks, sprints, jumps, and glides across heightmap and volumetric terrain in the same step. None of it was a tech demo for its own sake. It was the substrate for this.

Today the open world is live in early form. You put on an avatar and walk in. Your published games show up as visitable spaces around you, the way the storefront reels and the Top Performers chart show them now, except you arrive on foot instead of by swipe. You can drop into a stranger's game from the world without leaving the world. You can stand next to the person who made the thing you just played and tell them what you'd add next. You can sculpt a piece of terrain with someone you just met and turn it into the seed of a new project. Discovery stops being a feed. It becomes a walk.

Our engine has always been a game engine in the technical sense. Today it becomes one in the literal sense too. The thing that builds your game is now a game itself, and the same orchestrator from section 3, the same asset rails from section 4, the same getGameState contract from section 6, the same reels from section 8, and the same chart from section 9 all compose into the one place your players walk around in. The boundary between making and playing was always artificial. Now it's gone.

What we think we got right

The first thing we got right was treating the prompt as a UI affordance instead of a product. The product is the orchestrator, the tool surface, the asset rails, and the storefront. The prompt is the cheapest possible way to get a user into the system.

The second was insisting on a flat, browser-native filesystem with no build step. It's why a Cinevva game ships to mobile, desktop, Steam, and Discord from one source of truth. It's why the agent can read what it wrote.

The third was the contract that every generated game implements getGameState and setGameState. That single line in the system prompt is what makes the agent feel like a collaborator instead of a code generator. The agent can play, and a system that can play can debug.

The fourth was wiring the storefront into the same loop as the engine. We're not going to win on raw model quality. There's no defensible advantage in being two months ahead of an open-weights generator. We win when the same agent that builds your game also publishes it, measures it, and learns from how strangers played it.

If you want to see the whole machine in motion, the homepage prompt is still the front door. Type a sentence. Watch what happens behind it. Then come back here and tell us which piece of the engine to write up next.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Every spike since part 13 had followed the same recipe: copy the previous monolith, add one feature. By the end of spike 32 that monolith was 6,285 lines of index.html in a single <script type="module">. Code search was noisy, finding where to add a feature took longer than writing it, and any architectural change touched a file too big to diff in your head. Before adding another feature we paid down the structure.

Breaking the monolith with zero behavior change

Open Spike 33 in a new tab ↗ · View source

The constraint was strict: every split had to be a pure refactor, not a redesign. The monolith became 19 .mjs files plus a 151-line host shell. Top-level modules for scene, water, grass, character, physics, multiplayer, and UI, a wgsl.mjs that holds every WGSL source string as the single source of GPU truth, and a terrain/ subtree for heightmap, SDF, chunks, GPU buffer wrappers, brush, LOD, and persistence. Total code came out at 6,555 lines, basically the monolith plus import boilerplate. No net change in volume, a large change in navigability.

Then the page loaded to a black screen. Two error messages, two unrelated root causes. The first was a WebGPU complaint about a zero-byte buffer binding. In the monolith, the SDF brush buffer was lazily allocated when the first marching-cubes chunk appeared, and the bind-group factory happened to run later, after the buffer existed. Splitting terrain/gpu.mjs from terrain/brush.mjs reordered module evaluation so the factory now ran first and tried to bind a null placeholder. The fix was to defer bind-group creation to the first dispatch with a getOrCreateBindGroup(chunk) helper. The "create everything up front" pattern was an artifact of the monolith's single init path.

The second message was a scary-looking FBX skeleton warning that turned out to be a red herring. It had printed since spike 25 and was harmless. The character was missing only because the first bug cascaded: every compute dispatch threw, the heightmap never got written, height samples returned 0, and the character spawned at the origin and fell through the world. Fix the buffer, the character animates fine, warning and all.

That's the real lesson of the refactor. The monolith hid every "X must exist before Y is built" relationship inside top-to-bottom script order. Modularizing shuffled that order and surfaced three more latent ordering bugs: grass scattering before the heightmap upload, the water plane added before the environment map finished decoding, and persistence load completing after the first frame. All three were one-line fixes, and none would have been caught without the split.

A hundred props without growing anything

Open Spike 34 in a new tab ↗ · View source

Spike 34 was the test of whether the structure paid off. The goal was a first-person palette to place trees, rocks, bushes, mushrooms, and paths from a CC0 model pack, with terrain-aware alignment, persistence, multiplayer sync, and physics colliders, all without leaving the controls. Every line of new code landed in five new files under src/props/, and no existing module grew by more than ten hook-up lines.

The asset arc took a detour worth recording, because it's the kind of thing that eats a day. We started on Quaternius's Ultimate Nature pack, an FBX library with no embedded textures. The FBX materials shipped as MeshPhong with no map, so we wired a manual material-name-to-PNG table, converted Phong to Standard, and set color spaces by hand. About 30% of materials had no matching PNG and several names were ambiguous between similar trees. A second FBX pack had the same gap. The fix wasn't more mapping tables, it was a better-authored pack: Quaternius's Stylized Nature MegaKit ships 116 complete glTFs with embedded PBR materials and baked normals. Swapping FBXLoader for GLTFLoader deleted the cm-to-meters scaling, the texture table, and the Phong conversion, and shrank library.mjs by about 80 lines. The takeaway: glTF with PBR is the right pipeline for CC0 packs that ship it, and FBX with manual texture mapping was twice the code for half the quality.

A few sharp edges came with the glTF path. The palette renders 116 thumbnails, and WebGPU's canvas.toDataURL() returns blank for a GPUCanvasContext surface, so thumbnails render into a RenderTarget, read back with readRenderTargetPixelsAsync, and blit into a 2D canvas, minding WebGPU's 256-byte row alignment. Ghost previews clone each material to tint them green, which broke on meshes whose material is an array, fixed with an Array.isArray branch. And the 16-bit normal maps that shipped at ~200 MB got a one-off mogrify -depth 8 down to ~32 MB, visually identical since browsers downsample at upload anyway.

When the rendered geometry only exists on the GPU

The most instructive bug was the ghost preview snapping in 1 to 2 meter steps as the cursor moved. The terrain meshes store vertex positions in a StorageBufferAttribute because the compute pipeline writes them directly on the GPU, so three.js's CPU Raycaster can't see them and returns nothing. The fallback was a coarse 1.5 m ray-march against the analytic heightmap, and that fixed stride was the grid the user saw. We replaced it with an adaptive march: stride 2.5 m while high above the surface, shrink to 0.4 m within 5 m of it, then bisect 14 times when the sign of $({\text{ray}}_y-{\text{terrain}}_y)$ flips. That lands sub-millimeter precision at roughly 30 wide steps plus 14 bisections per cast. When the rendered geometry lives only on the GPU, don't fight the raycaster, march against the analytic source.

Colliders that stay honest through edits

We chose primitive proxies over convex hulls or mesh colliders. Quaternius props are blobby and low-poly with no meaningful concavities, so hulls would be roughly 50 times the code and 10 times the runtime cost for the same gameplay. Each prop reduces to one shape derived from its bounding box: trees and cacti to a vertical capsule, rocks to a sphere, logs to a horizontal capsule along the long axis, and decorative bushes and flowers to nothing. Rocks and logs are walkable (vertical-only push so you can stand on them), trees and cacti are blocking (full 3D push so you can't climb a trunk). An 8 m spatial hash keeps the per-frame test to the player's 3×3 neighborhood, typically zero to six props.

Two design decisions kept the system coherent. Terrain alignment is a manifest flag, not a category enum hard-coded in code, so the ghost preview and the committed placement read the same placement.alignToTerrain value and can't disagree. And placed props react to terrain edits through one helper: after a brush stroke (local or replayed from a peer), refreshPlacementsInRadius resamples the ground under every prop in the affected disc, re-applies alignment, and re-derives the collider endpoints. Sculpt a hill under a tree and the tree rides up with it. Persistence and multiplayer reuse spike 31's pattern exactly, storing a flat list of {uid, propId, x, y, z, rotY, scale} and mirroring place, remove, and nudge events over BroadcastChannel.

Technology referenced in this chapter

ES module decomposition under WebGPU. Splitting a monolithic <script type="module"> into bare-path .mjs imports needs no bundler when modules are served as static assets, and three.js TSL plays fine across module boundaries. The hidden cost is initialization order: a monolith encodes "build X before Y" in top-to-bottom script order, while modules evaluate in import order, which can run a GPU bind-group factory before its buffer exists. The fix pattern is lazy initialization (getOrCreate... on first use) and awaiting the right promise rather than relying on declaration order.

glTF with embedded PBR vs FBX with manual mapping. glTF ships in meters, references its own textures, and gives MeshStandardMaterial directly, so a CC0 pack authored as glTF drops straight into a PBR pipeline. FBX packs without texture-binding metadata require a hand-maintained material-name-to-PNG table that drifts on every pack update, plus a Phong-to-Standard conversion and manual color-space tagging. A foliage safety net promotes transparent materials with no alphaTest to alphaTest: 0.5 cutout cards so they sort correctly behind opaque geometry.

WebGPU offscreen thumbnails. canvas.toDataURL() returns blank for a GPUCanvasContext-backed canvas because there's no path from a presentation surface back to a 2D context. Rendering into a RenderTarget, reading pixels with readRenderTargetPixelsAsync, and blitting into a 2D canvas works, as long as the blit steps at WebGPU's 256-byte-aligned read-back stride. Results cache in localStorage under a version-bumped key so pack changes invalidate stale renders.

Adaptive ray-march against an analytic heightmap. When terrain vertices live in a GPU StorageBufferAttribute, the CPU raycaster can't see them. Marching the analytic height function with a large stride far from the surface, a small stride near it, and a binary-search refinement on the sign flip of $({\text{ray}}_y-{\text{terrain}}_y)$ gives sub-millimeter cursor precision in a bounded number of samples. The same primitive powers the brush cursor and the prop ghost.

Primitive capsule colliders with a spatial hash. Each prop is reduced to a category-derived capsule or sphere from its bounding box, recorded as {kind, walkable, radius, p1, p2} and registered in every 8 m hash bucket it overlaps. Per frame the player tests only the props in their 3×3 bucket neighborhood, one capsule-vs-capsule resolution each. Walkable proxies (rocks, logs) get a vertical-only push, blocking proxies (trees) get the full 3D push. See SDF terrain collisions for the capsule math this builds on.

Part 16 of 29. Previous: Part 15 - Replace the baseline, then sync it Next: Part 17 - Animations that didn't need retargeting, and a live asset search Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Mariana Muntean, CEO of Cinevva

In May 2022, I sat down for an interview with Ted Harrington's Tech Done Different podcast. The original write-up is still live on Medium. I had been running Cinevva for about two years. We had five people, $200K raised, a Mozilla Builders award on the wall, and a lot of opinions about where game development was heading.

Most of those opinions were not fashionable in 2022. Web3 was loud, AAA studios owned the conversation, GPT-3 was a research toy, and WebGL was something hobbyists used to make jam games. Saying "any creative will be a game developer" out loud got polite nods and zero checks.

I went back and read that interview last week. Some of what I said reads like wishful thinking. Some of it reads like I had a time machine. Here are the four bets that aged the best, with what 2026 actually looks like next to each one.

Bet 1: Game engines belong in the browser

What I said in 2022:

WebGL technology can be used across multiple platforms, including mobile devices, unlike other APIs that may be restricted to only PCs. So whether you're in the comfort of your home or on the move, you can still create and publish. WebGL games use only a fraction of the CPU and GPU power that a traditional PC game would require.

In 2022 this was a contrarian bet. The big engines all assumed downloads, installs, and patch cycles. Browser games meant Flash nostalgia and Friv.

In 2026, our open-world engine runs at 120 FPS in a browser tab. Terrain, trees, physics, multiplayer sync, all in one URL. No download, no app store, no install.

The browser caught up because three things landed at once. WebGPU shipped in every major browser. SharedArrayBuffer and cross-origin isolation became reliable. WebAssembly got fast enough to host real physics engines compiled from Rust. Our team published a 12-part field journal on what each of those steps actually cost. The summary is that the browser is now a real game runtime, not a place where you put the demo of the real game.

The bet I missed inside the bet: I underestimated how much of the work would be on the engineering culture side. Browser game engines are not held back by browsers anymore. They're held back by the assumption that a real game has a launcher.

Bet 2: AI is part of the pipeline, not a side feature

What I said in 2022:

For our platform to work flawlessly we use open source game tools, but also develop our own technology using Natural Language Processing, Computer Vision, and Open AI solutions, such as GPT3 for dialogues and DALL:E for text to image generation.

In May 2022, GPT-3 was a paid API most people had never used. DALL·E was barely a year old and wait-listed. Saying we were going to use them as production game-dev tools was, at best, ambitious cosplay.

In 2026, every serious creative pipeline has language models and image generation in it, including ours. Inside Cinevva today: ElevenLabs Music for soundtracks, ElevenLabs SFX for effects, Hunyuan3D and SAM3D for assets, Flux for visuals, Mubert for adaptive audio, AceStep for instrumentation. Prompts go in, usable assets come out, and the whole thing happens inside the editor.

The receipts on this one are in the GDC 2026 State of the Game Industry report. 52% of game companies say generative AI is being used in production. The same 52% of developers say AI use is having a negative impact on the industry. Both numbers are true. The point is that the underlying technology became table stakes faster than anyone wanted to admit.

What I got wrong: I thought the resistance would come from engineers worried about quality. Most of it came from artists worried about jobs. That conversation is much messier than I expected, and the people who treat it as a clean win are not paying attention.

Bet 3: Game development needs Google-Docs-style collaboration

What I said in 2022:

Source control and work with app versions are often linked with remote collaboration. Today to do that you have to know where to go, what version of the application you need to download, be in sync with everyone, God forbid one member on the team is on the wrong version of the app, it becomes a problem. We aim for a Google doc near real-time kind of experience: simple, effortless but fun.

Real-time collaboration in code tools was a fringe idea in 2022. Replit had it. VS Code Live Share existed. Most professional engines required Perforce, a VPN, and a senior engineer babysitting your branch.

In 2026, real-time collab is the default for any creative tool that wants to be taken seriously. Figma made it normal for design. Cursor and Bolt made it normal for code. Lovable made it normal for app prototyping. Game engines were the laggard, not the leader.

Inside our own engine we now have multiplayer sync working as a first-class spike, with chunk streaming, presence, and shared state in the browser. The experience is closer to "open the link, jump in" than "set up Perforce, ask Slack for the right version, install the launcher".

The piece I underestimated: the hardest part of real-time collab in games is not networking. It's conflict resolution on creative intent. Two people editing the same level at the same time is a UX problem before it's a sync problem, and most tools haven't solved it yet.

Bet 4: The future is indie

What I said in 2022:

Creatives who were not able to build game content will be able to do so. We will discover abundant new ways of how people perceive and express creativity. This time the process will not be controlled by corporations or big AAA studios only. The future is indie.

This was the most romantic line in the interview, and the easiest to dismiss in 2022. AAA budgets had never been higher. Indie projects had never had a harder time getting visibility. The math looked like it was going the other way.

In 2026, the math flipped. We made A Breaker Belt in three days, two people, on web, mobile, and PC from one codebase. That used to take a small team a quarter. Solo developers are shipping, not just vibing, and Steam Next Fest 2026 had record entries from teams of one.

The cost of finding out whether a weird idea works has collapsed. That's the real shift, and everything else, the AI in the pipeline, the browser as runtime, the real-time collab, is in service of it. A solo developer with the right tooling now has the production capacity that a 20-person studio had in 2018.

What I did not see coming clearly enough in 2022: the bottleneck moves from production to discovery. When everyone can ship, getting found becomes the hard problem. That's the next set of bets, and we're in the middle of making them.

What I got wrong on purpose

A few of the 2022 bets are still pending or need revision.

The Web3 angle was louder in that interview than it should have been. The encryption and zero-knowledge proof part holds up as a content-rights primitive. The token-and-marketplace framing aged poorly, and a lot of the energy I gave it in 2022 would have been better spent on AI tooling, where the real upside was.

I also underestimated how much of "anyone can make a game" is a discovery and distribution problem, not a tooling problem. Building is now easy. Getting found and getting paid are still hard, and they are where most of our work goes today.

That's the bet we're making right now. We just shipped a TikTok-style reels feed at cinevva.com/play. Vertical-swipe clips of actual gameplay, fifteen seconds each, no trailers and no marketing footage. If something catches your eye, one tap and you're playing it in your browser. No download, no install, no tutorial standing between you and the game.

The reason this matters for indie developers is brutal math. Steam Next Fest 2026 had a record number of entries, which sounds great until you do the per-game attention budget. Most demos got under a thousand impressions. The store-page funnel was already broken before AI made it worse. A scroll-and-swipe surface where the gameplay is the ad collapses the discovery loop into one motion. It puts solo developers in front of players the same way TikTok puts unknown musicians in front of listeners. That's the missing piece between "anyone can ship" and "anyone can succeed".

If you want the original interview in full, it's here. Reading it back was useful. Most of what we said out loud in 2022 turned out to be a working roadmap, just on a faster clock than we thought.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

For twelve parts we built a terrain engine that you could look at. Fly over it. Admire the seams not cracking. This time we wanted to touch it.

The goal sounded simple: let a player sculpt the terrain with a brush, in real time, without breaking any of the systems we spent 24 spikes building. It took three attempts, two bugs that looked like rendering failures but were data model failures, and a fundamental rethinking of how terrain data should work.

Three false starts

Spike 25 was supposed to be the easy one. The production codebase already had a raycaster that hits terrain meshes. The placement tool uses it for dropping objects. A brush tool follows the same shape, it just modifies heightmap values instead of spawning a prefab. Simple.

Attempt one: I built it directly into the production world/client/ TypeScript code. New terrain-brush.ts, modifications to chunk.ts, protocol changes, Vue component updates. Within an hour I had a brush that sort of worked, but chunk boundaries showed visible normal discontinuities. I couldn't tell if the bug was my brush code, the existing chunk stitching, or some interaction with the full render loop. That's exactly the situation the spike methodology exists to prevent. I'd skipped the rule and paid for it immediately. Reverted everything.

Attempt two: standalone spike, but I reached for Three.js 0.170.0 and WebGL. The production code uses WebGL, so it felt natural. But Spikes 13-24 had all moved to WebGPU. Building a WebGL brush spike would prove it works on the legacy renderer, not the one we're migrating toward. Wrong direction. Started over.

Attempt three: WebGPU, WebGPURenderer, compute shader for vertex generation, matching the Spike 22 stack. This time the architecture was right. Five brush operations working: raise, lower, smooth, flatten, noise. Brush cycle P95 under 4ms on M1.

And the seam bug was still there.

Open Spike 25 in a new tab ↗ · View source

The seam bug that wouldn't die

The standard fix for cross-chunk normal computation is border overlap: each chunk stores one extra ring of data from its neighbors, so the normal calculation at the boundary can sample both sides. I implemented that. Copied neighbor edge data into an expanded buffer. The seams still cracked.

I dug into the math. At the boundary between chunk A (cx=-1) and chunk B (cx=0), both chunks need to compute the same normal at the shared vertex. Chunk A's shader sampled mix(own_col31, own_col32, 0.85). Chunk B sampled mix(neighbor_edge, own_col0, 0.85). Those are different bilinear interpolation paths through different data. Even with correct border data, the two chunks compute different normals for the same point.

This was the moment I realized the border copy wasn't the real bug. The real bug was the data model.

Every spike from 1 to 24 used a procedural math function called height_at(). Feed it world coordinates, get a height. Clean, global, stateless. The brush couldn't modify a math function, so I'd added a displacement buffer on top. The terrain was now height_at(x,z) + displacement[i]. The GPU shader embedded 30 lines of noise functions for the base terrain plus bilinear interpolation code for the displacement overlay. The flatten brush had to subtract height_at() to figure out what displacement value would produce the target height. Two systems, layered on top of each other, computing different things with different sampling strategies.

None of that is how a real game works. In production, authored terrain is sampled data stored in buffers. The procedural function was a convenient stand-in from the early spikes. It had served its purpose. Now it was actively causing bugs.

I killed it.

Each chunk now owns a heightmap Float32Array with actual height values. At creation, procedural noise fills it. After that, the noise function is never called again. The brush modifies the stored heights directly. The GPU shader reads from one buffer using one function: hm_at(i,j). Normals use grid-aligned central differences on the same data. No bilinear interpolation ambiguity. No two-system mismatch. The shader went from 90 lines to 40.

The seams fixed themselves. Both chunks at a shared edge now read the same discrete height values from their respective buffers (with correct neighbor interior points in the border overlap). Same data in, same normals out.

This wasn't a brush lesson. It was a data architecture lesson that the brush exposed.

The exploding mesh

Spike 26 was the volumetric counterpart. Modify a 64-cubed SDF volume with a brush, then re-mesh with marching cubes. Same question as Spike 25, but in 3D.

The first time I ran it, the mesh exploded. Long spikes shooting in every direction, like a sea urchin having a bad day.

Open Spike 26 in a new tab ↗ · View source

The MC case table I'd generated had 3840 entries instead of 4096. The full table is $256\text{cases}\times 16\text{slots}=4096$, but I had $256\times 15=3840$, sixteen missing rows starting at case 112. Every lookup after that index was shifted, so the case number no longer matched the triangulation data. When marching cubes reads the wrong entry, it creates edges where both endpoints are on the same side of the surface. On a real crossing edge the interpolation parameter

lands in $[0,1]$ because $v_a$ and $v_b$ have opposite signs. On a fake edge they have the same sign, so $v_b-v_a$ is near zero or flips sign and $t$ shoots outside $[0,1]$, placing the vertex far outside the volume. Multiply that by a few hundred wrong cells and you get a hedgehog.

The fix was stupid simple: copy the proven table from Spike 12 byte-for-byte. Lesson learned. Never regenerate a lookup table when a proven copy exists.

The second bug was more subtle. The smooth brush was supposed to soften terrain features. Instead it created sharp creases. The problem: I was pulling every SDF value toward zero (the isosurface). That sounds like it should smooth things, but it collapses the distance field. Voxels above and below the surface both rush toward zero, flattening everything in the brush radius. At the boundary, smoothed voxels meet unsmoothed ones with a hard step. The "smooth" brush was a crease generator.

The fix was proper Laplacian smoothing. Instead of pulling each value toward zero, pull it toward the average of its 6 direct neighbors:

The term in parentheses is a discrete Laplacian, and $\lambda \in (0,1]$ is the smoothing strength. This averages nearby geometry, softening the surface shape while preserving the distance field gradient instead of collapsing it.

Everything at once

Spike 27 was the integration gate. Take Spike 24's full pipeline (heightmap patches, MC chunks, Transvoxel seams, geomorph LOD) and combine it with the sampled data model from Spike 25 and both brush types.

Open Spike 27 in a new tab ↗ · View source

The first thing I did was rip height_at() out of every shader. All three compute shaders (SDF fill, heightmap patch, Transvoxel seam) now bind the same 129x129 heightmap GPU buffer and use the same hm_sample() bilinear interpolation function through a shared WGSL preamble. One data source, multiple consumers. The procedural noise functions that had lived in every shader since Spike 1 were gone.

Then the interesting problems started.

When an SDF brush locks a chunk into MC mode, the Transvoxel seam between that chunk and its heightmap neighbor needs to sample from the SDF volume, not the heightmap. I extended the seam shader with additional storage buffer bindings and per-chunk MC flags. Four boundary combinations to handle: HM-HM, HM-MC, MC-HM, MC-MC.

LOD was another puzzle. In earlier spikes, switching an MC chunk to a lower LOD meant re-filling the SDF at a coarser resolution. I replaced that with stride-based sampling: SDF data stays at full resolution (65 grid points). The MC shader computes a stride from the ratio of grid size to cell count. At LOD0, stride is 1. At LOD1, stride is 2, sampling every other voxel. Chunks can change LOD freely without touching their SDF data.

The most satisfying fix was dynamic vertical chunk spawning. Sculpt upward past the top of a chunk, and a new MC-only chunk appears above it with its SDF initialized from the boundary face of the chunk below. Sculpt downward, same thing. The world grows to fit the edits.

The last gotcha was the heightmap brush silently doing nothing to MC-locked chunks. The HM brush modifies heightmapCPU and reuploads it. MC chunks don't read from the heightmap anymore because their SDF was filled from it and then diverged. I added syncHeightmapToSdf(): after the heightmap changes, re-derive the SDF columns for any MC chunks in the brush radius and upload the new values. Both brush types now work on both chunk types.

What we actually learned

The brush spikes were supposed to answer a performance question: can sculpting run within frame budget? It can. That was the easy part.

The hard part was discovering that 24 spikes of using height_at() as the terrain truth had created an invisible dependency that broke the moment we tried to edit anything. The procedural function was clean and global and stateless, right up until it wasn't the terrain anymore.

Rules we wrote down and won't forget:

1. Terrain height comes from sampled data. Chunks own their buffers.
2. Procedural generation fills initial data. It is not the runtime truth.
3. The brush modifies chunk data directly. No displacement overlays.
4. Normals come from the same data via grid-aligned central differences.
5. Border overlap (1 cell from neighbor interior) handles cross-chunk normals.
6. Never regenerate a lookup table when a proven copy exists.

In part 14 we stop sculpting debug geometry and start making it look and feel like an actual place.

Technology referenced in this chapter

Sampled heightmap architecture. Terrain stored as owned data per chunk rather than evaluated from a procedural function at runtime. Each chunk holds a Float32Array of actual height values. Procedural noise fills initial data at creation time, then the function is never called again. This eliminates the dual-system mismatch between math-based terrain and edit overlays, simplifies brush operations (edit stored values directly), and makes the GPU shader trivially simple (read from buffer, compute normals via grid-aligned central differences). For open world with streaming, per-chunk ownership with 1-cell border overlap from neighbors is the standard approach. See our landscape generation guide.

SDF brush operations. Modifying a signed distance field to sculpt terrain. Add (inflate) uses smooth-step falloff around a sphere. Subtract (carve) uses the same shape negated. Smooth uses Laplacian averaging: read the 6 direct neighbors, compute their mean, pull toward the mean. The naive approach of pulling toward zero collapses the distance field and creates sharp edges. Laplacian smoothing preserves the field gradient while softening features. See SDF terrain representation.

Transvoxel with mixed data sources. Transition cells at the boundary between an MC chunk and a heightmap chunk need to sample different data on each side. The seam shader carries per-chunk flags and buffer bindings to handle all four combinations (HM-HM, HM-MC, MC-HM, MC-MC). When one side is MC-locked, the shader trilinearly interpolates the SDF buffer instead of sampling the heightmap.

Stride-based LOD for marching cubes. SDF data stored at full resolution regardless of the chunk's current LOD level. The MC shader computes a sampling stride from the ratio of SDF grid points to MC cells. At full resolution the stride is 1, at half resolution the stride is 2. This decouples SDF data from LOD changes, so chunks can transition LOD freely without rebuilding the SDF.

Part 13 of 14. Previous: Part 12 - Rings, sky fog, and what we would do again Next: Part 14 - The world comes alive Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

After part 13 we had sculpting. Raise terrain, carve caves, smooth cliffs, all in real time, seams intact. But the world looked like a tech demo. Debug-colored flat shading, wireframe overlays, grey geometry with LOD colors to tell chunks apart. You could edit it. You couldn't feel it.

Three spikes changed that. Not the architecture. The exact same pipeline, buffers, and seam stitching from Part 13. We just added the layers that make terrain feel like a place: surfaces that respond to the shape, life growing on those surfaces, and a body that walks on them.

The difference between "technically working" and "I want to stay here" turned out to be surprisingly small.

Sculpt a cliff and watch it turn to rock

Spike 28 asked a narrow question: can a 4-layer material with triplanar mapping run on compute-generated terrain without killing frame budget? The answer was yes, but the interesting part was what happened next.

Open Spike 28 in a new tab ↗ · View source

Four procedural textures (grass, rock, sand, snow) generated from FBM noise at startup. No external files, no asset pipeline, just math and a DataTexture. The material weights come from the surface itself: slope and altitude. Flat areas below the treeline get grass. Steep faces get rock. Low ground gets sand. High peaks get snow. Each raw weight comes from a smoothstep on slope and altitude, then they're normalized per-fragment so $\sum _i{w}_i=1$ and the final color is just the weighted blend $\sum _i{w}_i{c}_i$. Normalizing is what keeps the surface from going dark or blown-out where biomes overlap. Triplanar mapping handles UV projection for MC chunks where triangles have no meaningful UV coordinates.

The moment that sold it: raise the terrain with the brush to create a steep cliff, and rock texture appears on the new face in the same frame. Flatten it back down, and grass reclaims the surface. The material doesn't know about the brush. It just reads world position and surface normal, the same data the geometry was built from. The sculpting-to-visual feedback loop is instant and unscripted.

Spike 8 tested terrain material cost a month and a half ago with a static mesh on WebGL. Spike 28 proves it works on dynamic compute-generated terrain with the full sculpting pipeline underneath. We'd budgeted for this, but seeing it hold at 60fps with everything running was still a relief.

80,000 grass clumps and a cave ceiling

Spike 29 is where the gamedev instincts took over.

Open Spike 29 in a new tab ↗ · View source

We wanted Breath of the Wild grass. Not the poly count, the feel. Grass that covers the right places, moves with the wind, and makes you want to run through it.

Each grass clump is three intersecting quads at 60-degree angles with four vertical segments for bending. It's a cross shape that looks volumetric from any angle without billboard tricks. One InstancedMesh per chunk, 80,000 clumps across the world, roughly 2.4 million grass vertices total.

Placement is the part that matters. The CPU walks a jittered grid across each chunk and evaluates the same slope/altitude logic the GPU material shader uses. Where the material system says "grass," grass grows. Where rock or sand dominates, density drops to zero. The falloff is smooth because the underlying smoothstep weights produce continuous gradients at biome edges. You don't notice a boundary because there isn't one.

Then we did something I wasn't sure would work. Grass on SDF surfaces. The scatter function walks each column of the SDF volume and finds zero-crossings between adjacent voxels. Where the SDF crosses from negative to positive, there's a surface. The surface normal is just the normalized gradient of the field, $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$, computed from voxel differences, and the slope is $\arccos (\hat{n}\cdot \hat{y})$, the angle from vertical. If that's gentle enough, place grass.

Carve a cave with the SDF brush in Spike 27. Come back in Spike 29 and there's grass growing on top of the cave ceiling. The scatter code doesn't know what a cave is. It just sees a surface with the right slope at the right altitude. That's the kind of emergent behavior that makes open-world systems satisfying to build.

Wind is a sine wave in the TSL vertex shader, modulated by the blade's V coordinate so tips sway and roots stay planted. Toggle V to cycle between gentle, strong, and off. The wind runs on all 80K clumps simultaneously with zero CPU cost because it's entirely in the vertex shader.

Spike 7 tested 50K grass instances and we were nervous about hitting the limit. Spike 29 runs 80K on top of compute terrain, seam stitching, multi-material texturing, and brushes. Batching into fewer InstancedMesh draws still matters more than reducing per-blade vertex count. The lesson from Spike 7 held up.

One thing we punted: grass doesn't update when you sculpt under it. The instance matrices are set at scatter time. Sculpt a hill into a valley and the grass floats in midair until you toggle G to re-scatter. Good enough for a spike. Production will need dirty-chunk re-scatter.

The first footstep

Spike 30 is the one I keep going back to.

Open Spike 30 in a new tab ↗ · View source

No physics library. Custom capsule at 120Hz fixed timestep. The production codebase uses Rapier in a web worker (Spike 2 proved the latency is fine), but this spike needed to prove the collision queries themselves. Can a character walk across heightmap terrain, step onto sculpted SDF terrain, and not fall through?

The core is a function called terrainQuery(x, y, z). It checks whether the position falls inside an MC-locked chunk. If so, it trilinearly interpolates the CPU SDF mirror and returns the gradient as a surface normal. Otherwise, heightmap lookup with central-difference normal. The character doesn't know which terrain system it's standing on. It just asks for the ground and gets an answer.

SDF collision was the part I expected to be hard. Seven probe points around the capsule (bottom, center, top, four cardinal offsets). A probe at position $\mathbf{x}$ is penetrating whenever $\varphi (\mathbf{x})<r$, with penetration depth $p=r-\varphi (\mathbf{x})$, and the push-out direction is the field gradient $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$. To stop the capsule re-entering the surface, velocity is projected to cancel its inward component:

which leaves only the component sliding along the surface. It's not a physics engine. It's geometry queries and simple response. But it handles caves, overhangs, and sculpted tunnels with zero special-case code per shape. You walk into a cave you carved ten seconds ago and the capsule follows the ceiling contour exactly.

The movement model started practical and got fun. Walk, run, sprint, jump, slope sliding above 45 degrees. Then I added a BotW paraglider and the spike turned into something I didn't want to close.

Press Space while airborne. Gravity drops from -30 to -4. Fall speed caps at -3. A delta-wing mesh unfolds from the capsule with scale interpolation. Bank left and the wing tilts. The capsule's facing auto-aligns toward the velocity vector so you're always looking where you're going. Let go of Space to drop. Hit the ground and you're running again.

The camera pulls back into third-person (toggle P). It follows behind the player with yaw smoothing. A ray-march from player to camera tests terrain at 20 steps. Fly into a cave and the camera arm shortens smoothly instead of clipping through rock. Emerge on the other side and it extends back out.

Here's the moment that made the spike worth it: sculpt a tall cliff with the heightmap brush. Switch to the third-person camera. Run to the edge. Jump. Deploy the glider. Bank left over the terrain you just sculpted, with the grass you grew in Spike 29 waving below, the rock texture from Spike 28 on the cliff face, Transvoxel seams holding at every chunk boundary. Land on the other side. Everything working together in one browser tab.

Sculpting under your own feet

One thing I wasn't sure about: what happens when you sculpt the terrain the character is standing on? The heightmap changes propagate through terrainQuery() instantly because it reads the CPU buffer directly. SDF changes propagate through the CPU SDF mirror. The capsule resolves penetration on the next physics tick, which at 120Hz is within $\frac{1}{120}\approx 8.3$ ms.

It just works. Raise the ground under the player and they rise with it. Carve the ground away and they fall. No special handling. The physics runs fast enough that single-frame terrain changes never produce large penetrations. This was a happy accident of choosing 120Hz for the timestep. We picked it for smooth movement, and it made terrain editing safe for free.

30 spikes later

We started this series with a flat heightmap and 500 cubes. Now we have sculpted terrain with volumetric caves, Transvoxel seam stitching, multi-material texturing that responds to the surface shape, 80,000 grass clumps swaying in the wind, and a character that walks, sprints, jumps, and glides across all of it.

None of this is in production yet. The world/client/ codebase still runs WebGL with simple heightmap chunks. Everything from these 30 spikes lives in standalone HTML pages. The integration work is next: migrating to WebGPURenderer, wiring the hybrid HM/MC policy into the chunk manager, connecting the brush and material systems to multiplayer.

But the rendering system isn't the risk anymore. The open questions are about data flow: edit persistence, network sync of brush strokes, collaborative sculpting. The stuff that happens between players, not between triangles.

If you've followed this series from Part 1, thanks for sticking with the messy parts. If you just found this, go back to Part 1. The wrong turns are where the lessons live.

Technology referenced in this chapter

TSL (Three Shading Language). Three.js's node-based shader system for the WebGPU renderer. Materials are composed from nodes (positionWorld, normalWorld, smoothstep, triplanarTexture) using function composition in JavaScript. The shader graph compiles to WGSL at runtime. TSL replaces raw GLSL ShaderMaterial for WebGPU targets and provides interop between standard Three.js material features (lights, shadows, fog) and custom per-fragment logic.

Triplanar mapping. A texture projection technique that samples a texture three times (XY, XZ, YZ planes) and blends based on surface normal direction. This eliminates UV stretching on arbitrary mesh geometry, which is critical for marching cubes output where triangles have no meaningful UV coordinates. TSL provides triplanarTexture() as a built-in node.

Instanced vegetation with cross-quad blades. Each grass clump is 3 intersecting quads at 60-degree angles, creating a volumetric appearance from any view direction. 4 vertical segments per quad allow smooth bending for wind animation. The entire field is rendered as a single InstancedMesh per chunk. Capacity is over-allocated by 25% so new instances can fill reserved slots when terrain is edited without reallocating the GPU buffer. See our landscape generation guide on vegetation.

Capsule vs SDF collision. Character collision against volumetric terrain without a physics engine. The capsule is probed at multiple points against the SDF. Where the field value is less than the capsule radius, the gradient provides the outward normal and the difference gives the penetration depth. This handles caves, overhangs, and tunnels with no shape-specific code. See SDF terrain collisions.

Fixed-timestep character controller. Physics steps at 120Hz regardless of frame rate, accumulating real time and consuming it in fixed-size steps. A max substep count prevents spiral-of-death on slow frames. Ground snapping keeps the capsule attached during slope traversal. The fixed timestep ensures deterministic behavior for future multiplayer replay.

Part 14 of 29. Previous: Part 13 - Terrain sculpting and the death of the math function Next: Part 15 - Replace the baseline, then sync it Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

The first fourteen parts covered spikes 1 through 30. That run ended with a terrain system that could be sculpted in real time, plus a character who could walk, glide, and fall on it. This part picks the series back up at spike 31, and the first thing we had to decide wasn't technical. It was what to do with all that spike code.

The "replace, don't backport" decision

We had 30 standalone HTML files, each proving one isolated concept, and zero integration. The production world/client/ was still the old stack: WebGL, a simple heightmap, a 75-line character controller, a MessagePack protocol with nine message types. No editing, no WebGPU, no materials, no vegetation.

The obvious plan was to backport spike results into that production codebase one at a time. We threw it out. Spike 30 already had better terrain, physics, materials, vegetation, and camera than world/client/ ever did. Backporting into the old WebGL code would mean fighting it the whole way. So we made the call to replace the world implementation with the most successful spike and build forward. Spike 30 became the new baseline, and world/client/ became dead code.

That reframed the remaining work. To get from "great single-player tech demo" to "product" we needed multiplayer, persistence, infinite-world streaming, and object placement. Multiplayer terrain sync went first, because it's the one that forces architecture. The question it answers is simple to ask and expensive to get wrong: when Player A sculpts, what actually goes over the wire?

Brush-param replay, not pixel sync

Open Spike 31 in a new tab ↗ · View source

Before writing a line of network code, we traced exactly what a brush stroke does. The heightmap brush walks a radius around the cursor in a CPU Float32Array, applies a smoothstep falloff, and either adds, subtracts, smooths, or flattens. The SDF brush does the same thing in 3D over a sphere of voxels. Both paths are pure CPU array math. No GPU compute in the loop, no randomness, no nondeterministic floating point. Same input array plus same params equals same output, on every machine.

That's the whole trick. We don't send the edited terrain. We send the brush parameters, 56 bytes per stroke tick, and every client replays the same deterministic function. The sync protocol is four message types: peer discovery, the brush message {op, wx, wy, wz, radius, strength, flattenTarget}, and a player-position message at 20Hz.

For the spike we skipped the server entirely and used BroadcastChannel, the browser API for same-origin cross-tab messaging. Open two tabs, they talk, zero infrastructure. That isolates the sync question from latency, auth, and Durable Object wiring. If param replay converges across tabs, it'll converge across a WebSocket too.

The one place replay can diverge is order-dependent operations. Raise and lower are commutative, so val + strength * falloff lands the same regardless of who applied first. Smooth and flatten read neighbor values, so two clients smoothing the exact same spot in the same instant can drift by fractions of a millimeter per tick. In practice that never fires, and the production fix is already obvious: route edits through the DO, let it assign a monotonic sequence number, apply optimistically on the client, and correct order if the authoritative sequence disagrees. Classic optimistic concurrency, and the DO is a natural serialization point anyway.

The peer capsule that kept vanishing

Edits synced on the first try. The remote player's capsule did not. It flickered in and out of existence on the other tab, and it took three separate bugs to make it stay solid.

The capsule spawned at the world origin, which is buried under the terrain, because the join message arrives before any position data. Fix: start it hidden and reveal it on the first position update. The position broadcast lived inside the render loop, and Chrome throttles requestAnimationFrame on unfocused tabs, so the other tab's staleness check would reap the peer and the next message would recreate it. Fix: move the broadcast to a setInterval, which isn't throttled for visible tabs. And the staleness timeout was a too-aggressive 5 seconds, tripped by any GC pause. Fix: raise it to 30 seconds and rely on the clean leave message for normal closes.

Persistence and late-join, same format

We folded persistence into the same spike instead of spinning up a new one, because the serialization format is identical whether the destination is IndexedDB or another tab. A snapshot is the full heightmap (a 129×129 Float32Array, about 66 KB) plus only the edited SDF chunks (each ${65}^3$, about 1.1 MB) plus the list of chunk IDs locked into marching-cubes mode. A debounced save writes to IndexedDB two seconds after the last edit. On load, procedural terrain generates synchronously and then the saved state overwrites it before the first meaningful frame. Late-join reuses the exact same bytes: when a new tab joins, an existing tab with edits serializes its state and sends it targeted at the newcomer, and the mountain you sculpted five minutes ago appears on their screen.

The first persistence test surfaced a nice ordering bug. Grass is scattered synchronously at init using the procedural heights, but the IndexedDB restore is async and overwrites the heightmap afterward, leaving every blade floating or sunk. The fix is a refreshAllGrass() pass that resamples the height under each instance and hides any blade now on a bad slope or altitude. The same function serves both load and late-join.

The slope saga

Sculpted terrain is rougher than the smooth procedural baseline, and it exposed three physics bugs the old terrain never could. Walking straight uphill made the capsule slide sideways. The cause was a velocity projection meant to keep movement tangent to the ground, but written with only the horizontal components of the normal. On a diagonal slope with normal $(-0.3,0.9,-0.3)$, walking north injected sideways velocity out of nowhere. The ground snap already keeps the player on the surface, so we just deleted the projection.

The drift persisted from a second source. The SDF collision probes push the body out along the gradient by the penetration depth. On any slope the gradient has horizontal components, so a 0.1 m penetration on a 15° slope pushes about 0.026 m sideways per step, and at 120Hz that's roughly 3 m/s of invisible drift. Fix: split the response by slope. On walkable ground (${\text{grad}}_y$ above the walk threshold) the push is vertical only. On walls and cliffs the full 3D push stays, because that's exactly where you want to be deflected. We also raised the walkable limit from $\cos 45°$ to $\cos 60°$ so brush-made hills feel climbable the way they do in Breath of the Wild.

The third bug froze the capsule at chunk boundaries, because collision probes sampled a single chunk's SDF and got the "deep in air" sentinel when a probe crossed into the neighbor. The fix was sdfSampleWorld(wx, wy, wz) and sdfGradientWorld(...), which find the right chunk for any world position and fall back to a heightmap distance estimate where no SDF exists. The SDF-to-heightmap collision transition is continuous now.

Water completes the world

Open Spike 32 in a new tab ↗ · View source

Every spike up to here was "land above water." Spike 32 added an ocean, and with it a new movement verb. We set the water level at 22 in a terrain that ranges roughly 8 to 58, which floods the low valleys, leaves beaches at the shoreline, and keeps plenty of dry land for play.

The surface is a MeshStandardNodeMaterial built in TSL, the same node approach as the terrain. Three overlapping sine waves at different frequencies displace the vertices, and the surface normal comes from the analytic cosine derivatives of those waves rather than from mesh normals. Color blends from turquoise shallows to dark teal depths using a depth estimate $(\text{level}-y+\text{wave})\times 0.12$ clamped to $[0,1]$, foam rises where that estimate approaches zero at the shoreline, and alpha follows depth so shallow water reads as transparent and deep water as nearly opaque.

Swimming is a buoyancy spring. The player enters swim mode when the feet drop below the water level and the body center is within a capsule half-height of the surface. A spring pulls the body toward a target just under the surface, and with a buoyancy constant of 12 against a water damping of 4 the player bobs stably with their head out, no oscillation. Swim speed is slower than walking with floaty acceleration and drag, jumping near the surface launches you out at 60% of normal jump velocity, and entry caps downward velocity at -5 m/s so you don't plunge. Terrain collision still runs underwater, so you can walk the lake bed where it rises above the swim target. The swimming flag rides along in the position broadcast so peers see you swim, and an HTML gradient overlay tints the view when the camera dips below the surface.

Technology referenced in this chapter

Deterministic brush-param replay. Instead of streaming edited terrain, each client sends only the brush parameters and replays the same CPU function. This works because both the heightmap and SDF brushes are pure Float32Array math with no randomness or GPU nondeterminism, so identical inputs produce bit-identical outputs everywhere. Payload is 56 bytes per stroke tick. Commutative operations (raise, lower) converge regardless of order, while neighbor-reading operations (smooth, flatten) need a serialization point to guarantee convergence, which the production Durable Object provides via monotonic sequence numbers.

BroadcastChannel as a WebSocket stand-in. A browser API for same-origin cross-tab messaging with zero server. Used here to test the sync protocol in isolation from network latency and authentication. The serialization format (raw Float32Array heightmap plus edited SDF chunks plus MC-locked chunk IDs) is the same bytes used for IndexedDB persistence and late-join state transfer, so one format covers three jobs.

Slope-split SDF collision response. When a capsule probe penetrates volumetric terrain, the naive fix pushes the body out along the SDF gradient by the penetration depth. On slopes that gradient has horizontal components, injecting lateral drift. Splitting the response so walkable surfaces (${\text{grad}}_y$ above threshold) get a vertical-only push, while steep surfaces keep the full 3D push plus velocity projection, removes the drift without losing wall collision. See SDF terrain collisions.

TSL water with analytic wave normals. The ocean is a node material whose vertices are displaced by three summed sine waves. Rather than recomputing mesh normals after displacement, the surface normal is derived analytically from the cosine derivatives of the wave functions, which is cheaper and avoids the artifacts of finite-difference normals on a coarse grid. Depth-driven color, shoreline foam, and depth-driven transparency all key off a single depth estimate.

Buoyancy-spring swimming. Swim physics models the body as a damped spring pulled toward a target just below the surface. With buoyancy constant 12 and damping 4, the player settles at the surface without oscillating. Distinct movement constants (slower speed, floaty acceleration, heavy drag) give swimming a different feel from walking, and the existing capsule-vs-terrain collision keeps working underwater.

Part 15 of 29. Previous: Part 14 - The world comes alive Next: Part 16 - Structure for a world that keeps growing Series guide: /blog/2026-02-25-open-world-browser-series-guide

Based on the sketch-to-video-to-3D pipeline and Kali the Kitty (Cubcoats). For licensing, blog, or partner pitch.

To share as PDF: Open this page, then use your browser's File → Print → Save as PDF.

Golden Tree — Full one-pager

Tagline: A world that grows with you. Visit, water, watch. No levels. No pressure.

What it is

A calm, collectible world that evolves in real-world time. One shared "season" (e.g. Spring Island): a single 3D island kids can walk around (like the playable Kali demo). There are no traditional levels or scores. Progression is your tree got a new branch, you've seen 12 moments, someone watered your seed.

Each visit a child can: water one plant, leave one wish (text or emoji), find one hidden Cubcoats character, or watch one 30-second "moment" (e.g. Kali under the golden tree). New moments and small story beats drop weekly (episodic). Optional ambient language: "Today Kali said: [one line in EN and ZH]."

Learning and growth are subliminal: themes (kindness, patience, trying again) live in the writing and art, not in lessons. The experience feels like a toy or a shared place, not school.

Core loop

1. Visit the island (browser or app).
2. Do one gentle action per visit: water, wish, find a character, or watch a moment.
3. See the world change over days/weeks (new flowers, new character poses, new short clips).
4. Share a seed to a friend or "visit a friend's island" so growth feels social.

How it uses the article's pipeline and characters

• 3D playable world: Same pipeline as the Kali demo: T-pose → 3D Model Generator → rigging → Cinevva Engine. The island and characters are explorable, third-person, low stakes.
• Golden tree: Directly from the article (Kali's "fear to hope" beat and the magical golden tree). The tree is the emotional and visual anchor of the season.
• Short "moments": Produced like the article's vertical short: start frame + end frame + motion prompt → Video Generator (Kling 3.0 Pro), 9:16, ~15 s. Each weekly drop is one small story beat.
• Cubcoats IP: Kali and the other seven characters, the island world, and the warm, rounded art style. Fits a licensing-first relaunch (2026) with a digital, episodic product.

Why it can go viral

• Low friction: One link, no heavy onboarding. "Send your friend a seed" is a simple share.
• Calm, beautiful clips: The short moments are standalone shareable (social, "watch this 15 seconds"). Meme-friendly in a positive way.
• Episodic: "What's new this week?" drives return visits and conversation.
• Subliminal: Parents see "calm, creative, no ads, no stress"; kids get routine, patience, and gentle surprise without being taught explicitly.

Possible Cinevva blog angle

"We took Kali from sketch to video to a character you can walk around. Golden Tree is the next step: a world that grows in real time, where kids visit, water, and watch short moments—no levels, no pressure. Same pipeline. New format."

Kali's Word Island — At a glance

Core idea: The Cubcoats island is split into character zones (Kali's forest, another's beach). Kids help characters by doing short tasks that require understanding and producing EN/ZH. Progression = "Seeds → Saplings → Trees → Golden Tree" (unlock next zone when the zone's tree is full). Daily "lantern" run, phrase cards as collectibles, character "mood" bars, optional parent dashboard. Short story moments (start/end frame style) unlock when a zone is complete. Pipeline: Same 3D + video pipeline for characters and emotional beats.

Cubcoats: Island Stories — At a glance

Core idea: Episodic narratives where kids choose branches (what does Kali say? where does she go?). The main activity is remixing: pick character, place, 2–3 beats → output a short "episode" (script + simple visuals, or later AI-generated short). Learning is subliminal (vocabulary and patterns in dialogue and choices). Social: share your episode, play someone else's version, rate "kind / funny / surprising." Pipeline: Same character look + two-frame video pipeline for user-generated "moments"; 3D for character/world consistency.

Cinevva tools referenced: Image Generator, Video Generator (Kling 3.0 Pro), 3D Model Generator, auto-rigging, Cinevva Engine. Reflects the pipeline described in "From sketch to video and playable 3D" (2026-03-04).

By Mariana Muntean, CEO of Cinevva

The team at Cinevva just published one of the most transparent engineering journals in recent game-dev memory: a 12-part series documenting our attempt to build a multiplayer open world that runs entirely in the browser. No download. No app store. Just a URL.

The project spanned 24 technical experiments we call "spikes" -- short, focused prototypes designed to answer one risky question each. Every spike shipped with live source code you can open and run in your browser right now. The series was written by Oleg Sidorkin, CTO and co-founder of Cinevva, and it reads less like marketing and more like a field journal from the frontlines of what browsers can actually do in 2026.

What makes the series worth reading -- even if you never plan to build terrain systems -- is the method underneath. It's a case study in how to de-risk an ambitious project before you've committed to anything expensive.

Starting with the hardest question first

Most open-world projects die in a predictable sequence. First you get a beautiful concept. Then a pretty scene. Then you discover that your frame budget was already spent before gameplay existed.

Our team inverted the order. The first spike was deliberately ugly: a 512-meter terrain mesh, 500 instanced objects, procedural height noise, a water plane, and fog. No shadows, no beauty pass. The only question was whether a browser could hold a stable frame rate while the camera moved through it.

It could. And that "yes" established something Oleg calls a "baseline contract" -- a measured reference cost for a minimal scene that every subsequent feature had to justify itself against. If a new effect looked great but blew the frame budget, it didn't ship. Not yet, anyway.

That kind of discipline sounds obvious. In practice, it's rare in fast-moving prototype environments where everyone is excited about the next visual win.

The physics gamble

The second experiment tackled an architectural debate that divides browser game developers: should physics run on the main thread, where it's simpler, or in a Web Worker, where it can't block rendering?

Worker-based physics is cleaner on paper. In practice, the fear is latency. Every input event has to cross a message boundary twice: once to reach the worker, once to bring back the result. If that round trip is too slow, pressing a key and seeing your character move will feel sluggish.

The team integrated the Rapier physics engine (compiled from Rust to WebAssembly) in a dedicated worker, wired up the message pipeline, and measured. The overhead was negligible. Controls still felt immediate. But we were careful to note that we'd validated one specific scenario, not a universal rule. When GPU pressure and streaming complexity changed later, assumptions would need rechecking.

The boring spikes that saved the project

Part three of the series has no screenshots. It covers three experiments that looked unglamorous but carried product-level consequences.

The first tested whether Cloudflare Durable Objects could handle real-time position broadcasts at game-like tick rates -- the multiplayer backbone. If this had failed, the entire network architecture would have needed early sharding rather than single-island ownership.

The second validated a mobile quality profile: not a desktop preset renamed, but an explicit low-cost rendering path from the same terrain baseline. The question was whether the world could remain readable and responsive under mobile GPU constraints without rewriting the renderer.

The third evaluated whether AI-generated behavior scripts for creator workflows would be reliable enough for production use.

None of these produced demo reels. All three set hard boundaries that shaped every architectural decision afterward. Oleg writes that these "unflashy spikes changed architecture faster than visual spikes did."

Streaming: where pretty projects fall apart

You can hide a lot in a still frame. You can't hide a 40-millisecond stutter when crossing a chunk boundary while running.

The team tested streaming before building advanced terrain, deliberately separating concerns. Spike 6 validated neighborhood chunk loading with simple content. Only after that clean signal did Spike 11 introduce compressed heightmap streaming with progressive refinement -- loading terrain at 17-sample resolution first, then 33, then the full 65-sample grid.

The sequencing mattered more than we expected. Had we started directly with compressed height chunks, every hitch would have been ambiguous. Was it a decode issue, a texture upload stall, or a geometry update problem? Testing simple streaming first eliminated one entire category of uncertainty.

A practical lesson emerged: measure upload stalls directly, not through average FPS. Averages hide frame spikes, and frame spikes are what players actually feel.

The visual budget wars

Three separate experiments attacked rendering costs in isolation rather than bundling them. Vegetation density and wind animation. Multi-layer terrain materials with triplanar mapping for cliff faces. Cascaded shadow maps under realistic terrain load.

The vegetation spike revealed that batching instances into fewer meshes mattered more than reducing per-blade polygon count. The material spike found that triplanar projection on vertical surfaces was worth the GPU cost, but adding a fifth texture splat layer wasn't. The shadow spike determined that three cascades at 1024 resolution delivered acceptable contact shadows without exceeding 2 milliseconds of GPU time.

The team adopted a blunt rule: a feature moves forward only if it can explain its cost with measured frame-time data. That constraint, set early, made later architectural decisions around volumetric terrain and clipmaps significantly cleaner.

The pivot that changed the project's trajectory

Before Spike 10, our mental model was "bigger world means more geometry." After Spike 10, it became "constant geometry budget, camera-centered ring updates."

Geometry clipmaps -- concentric rings of terrain centered on the camera, each ring progressively coarser -- meant the triangle count stayed roughly constant regardless of draw distance. The practical trick was geomorphing at ring boundaries: smoothly blending vertex heights in the shader so that the shift between resolution levels is invisible in motion.

A subtle lesson came from testing methodology. Clipmaps look fine in screenshots. They reveal their artifacts only under sustained camera movement through ring boundaries. The team spent time running constant-speed traversals and watching for temporal noise. "Screenshots lied," Oleg writes. "Motion told the truth."

Going underground

Heightmaps can't represent caves. They store one elevation value per point on a grid. The moment you need tunnels, overhangs, or carved rock faces, you need volumetric terrain.

Spike 12 implemented marching cubes on the GPU using WebGPU compute shaders, extracting triangle meshes from a 3D signed distance field. Four 64-cubed chunks ran simultaneously with per-frame mesh updates from animated SDF edits. The compute shader handled everything -- evaluating the field, classifying cells, emitting vertices -- without any CPU readback.

The challenge wasn't making it work. It was making it work alongside everything else. Integration with Three.js's scene graph, buffer lifecycle management (WebGPU buffers can't be resized), fence handling to avoid destroying GPU resources still in flight -- the series devotes two full parts to what we call "incremental hardening," the unglamorous process of adding one capability at a time and verifying the previous layer still functions after each addition.

The seam nightmare

The most technically harrowing section of the series spans Parts 9 through 11, covering what happens when terrain chunks at different resolutions meet.

When a high-detail chunk sits next to a low-detail chunk, their independently generated meshes don't align at the boundary. The result is visible cracks, flickering edges, and T-junctions where light bleeds through. The Transvoxel algorithm solves this with special transition cells that bridge resolution differences -- but implementing it correctly across all chunk configurations, with consistent winding order, proper buffer management, and accurate draw ranges, consumed six separate experiments.

The team's most memorable debugging story: two days chasing a seam artifact we blamed on transition logic. The actual culprit was stale data. The GPU compute shader wrote N vertices into a buffer, but the draw call was still configured to render N+M vertices from the previous frame. Those extra vertices contained garbage that produced flickering razor-thin triangles. One line fix: clip the draw range to the atomic counter's active vertex count.

"Rendering bugs often masquerade as meshing bugs," Oleg observes. "The geometry was correct the whole time."

From chaos to governance

After the seam battle, the team replaced ad-hoc chunk behavior with an explicit policy system. A central function now decided each chunk's LOD level, rendering mode (heightmap or marching cubes), and which faces needed transition cells. Distance rings determined the base LOD. An adjacency constraint ensured no two neighboring chunks differed by more than one resolution level. An edit bitmap kept volumetric chunks in marching-cubes mode regardless of distance if they contained creator modifications.

Color-coded debug overlays -- green for heightmap chunks, blue for marching cubes, orange for transition faces -- turned "I saw a bug somewhere near that ridge" into "the bug appears at position (142, 12, -67) facing northwest."

"Policy didn't reduce complexity," Oleg writes. "It organized complexity."

What it adds up to

The final spike combined clipmap rings, per-fragment sky fog (sampling the actual skybox color in the direction of each terrain fragment), and Three.js module wiring into a unified demonstration. The result is a terrain system that layers near-field volumetric editing, mid-field heightmap chunks, and far-field clipmap rings under a policy layer that governs mode, LOD, and transitions.

The series closes with lessons Oleg says he'd repeat on any future project:

• Start with risk spikes before feature work. Kill the "can we even do this?" questions before investing in content pipelines.
• Freeze known-good baselines before integration jumps. The day spent establishing a clean checkpoint saves multiple days bisecting regressions later.
• Force policy and observability before optimization marathons. Named conditions with trigger rules beat mystery bugs every time.
• Test under motion, not screenshots. Pops, flicker, and streaming hitches all hide in still frames.
• Measure per-feature frame time, not average FPS. Averages hide the spikes that users actually feel.
• Publish the messy parts. The wrong turns, the ghost hunts, the two days blaming the wrong system. Those are the parts people can actually learn from.

Why this matters beyond Cinevva

The series is significant for three reasons that extend past one company's terrain pipeline.

First, it demonstrates that WebGPU compute shaders, WebAssembly physics, and edge-deployed Durable Objects have crossed a threshold. A multiplayer open world with volumetric terrain, real-time editing, and streaming LOD is architecturally viable in a browser tab in 2026. That was not true two years ago.

Second, the spike methodology -- small, focused experiments that each answer one risky question with live, measurable results -- offers a template for any team attempting something that might not work. The discipline of measuring before committing, of establishing baselines before integrating, of naming edge cases before optimizing, applies far beyond terrain systems.

Third, the radical transparency is the point. Publishing source code for all 24 experiments, including the dead ends and the two-day debugging detours, makes this more than a technical blog. It's a public engineering notebook that treats the reader as a colleague rather than a customer.

The full series is available in our series guide, with every spike running live in the browser.

This article was originally published on Medium.

By Oleg Sidorkin, CTO of Cinevva

Taking a character from a flat sketch to a playable 3D game used to require a concept artist, a 3D modeler, a rigger, an animator, and someone to wire it all together in an engine. We wanted to see how much of that pipeline Cinevva's creative tools could handle on their own. Here's what we found.

The character is Kali the Kitty from Cubcoats, a children's brand that sold over a million stuffed-animal hoodies through Nordstrom, Amazon, and Disney Store. Cubcoats has eight original characters with defined personalities, a fictional island world, and 14 patents. They're relaunching in 2026 as a licensing-first platform, and we wanted to show what that IP looks like when it moves beyond physical products: a vertical video short and a rigged 3D character you can walk around in a browser. Everything below is real output from that exploration.

Drag the 3D viewers to orbit. Scroll the film strip to see how the vertical short moves from first frame to last.

From flat book art to a character you can spin around

Cubcoats already had beautiful 2D illustrations. Mimi Chao's art direction gave every character a warm, rounded, hand-drawn look that works perfectly on hoodies and in storybooks. But flat art doesn't feed a 3D pipeline. We needed a high-fidelity character that could hold up as a reference for video generation, mesh creation, and rigging, all from the same face.

We started by feeding the original book illustrations into our Image Generator and asking it to produce a 3D rendered version of the same character.

The proportions held, the personality came through, and the soft 3D cartoon look gave every downstream tool something consistent to agree on. From there we iterated on the exact pose and framing until we had a locked hero reference.

The T-pose matters because rigging expects arms away from the torso. Skip it and the auto-rigger fuses the arms to the body and gives up. We generated the T-pose from the same locked character look so the silhouette and proportions stayed consistent across every step.

Write the story before you generate anything

Before touching video tools, we wrote a beat sheet in plain language. Kali's personality trait in the Cubcoats universe is "Positive." She's the one who makes everyone feel included, stays upbeat when things get hard. So we built a ten-second arc around that:

Kali walks into a dark misty forest at night holding a tiny glowing lantern. She gets scared, sits down alone, almost gives up. Then she discovers a magical golden tree lighting up behind her. Wonder, joy, golden particles raining down. Fear to hope in one breath.

That's the whole plot. It doesn't need to be complex. It needs to fit one emotional turn into one continuous shot so the start frame and end frame can actually connect.

Two frames that bookend the whole thing

We generated two key stills from that plot using our Image Generator. Portrait aspect to match the vertical short. The prompts describe the exact same character in two different moments.

Start frame prompt:

3D animated Pixar-style render of Kali, a small pink kitty character with large round dark eyes, pink pointed ears, a light pink belly, and a cheerful round face. She is standing at the edge of a dark misty forest at night, holding a tiny glowing lantern in both paws. Her ears are slightly flattened and her expression is nervous but determined. Cinematic lighting with cool blue moonlight from above and warm orange glow from the lantern. Dense fog between dark tree trunks in the background. Camera angle: medium shot, slightly low looking up at her. No text, no watermark.

End frame prompt:

3D animated Pixar-style render of Kali, a small pink kitty character with large round dark eyes, pink pointed ears, and a light pink belly. She is standing in front of a massive magical tree covered in glowing golden flowers, arms outstretched wide, beaming with a huge joyful smile. Golden petals float in the air around her. The tree radiates warm golden light that illuminates the entire forest clearing. Starry night sky visible above. Camera angle: wide shot from slightly below, epic reveal composition. No text, no watermark.

Seedance interpolates between these two bookends. The character description stays identical across both prompts so the model knows it's the same person. Only the scene, emotion, and camera change.

The video came out better than expected

We loaded both frames into Cinevva's Video Generator, picked Seedance 1.5 Pro, set 9:16 aspect and 15 seconds, typed the plot into the motion prompt, and hit Generate.

The clip interpolates between the two bookends. Native audio was generated in the same pass. Here are frames sampled along the timeline.

Left to right: progression through the generated vertical short.

Start plus end frame was the right mode when we cared about hitting an exact closing pose. For longer emotional arcs, single reference plus prompt worked well with the Video Generator's Kling 3.0 Pro storyboard mode. Different settings for different jobs.

Same character, now in 3D

Here's where it gets interesting. The T-pose still from the same family as the video references went to our 3D Model Generator for image-to-3D generation. You're not matching the game mesh to the video pixel for pixel. You're matching player memory. The character in the game should feel like the same personality as in the reel. And because we locked one visual identity at the start, it did.

The 3D Model Generator outputs a textured GLB. Not game-ready, but recognizably Kali. The silhouette matched. The materials were close. Good enough to move forward.

Drag these around

Raw output from the 3D Model Generator. No rig, just a textured mesh. Next to it, the same character after auto-rigging with a baked walk animation.

Rigging and animation

The 3D Model Generator gives you a mesh. To make that mesh move, it needs a skeleton and animations. Our platform handles rigging automatically: upload the GLB, get back a rigged model with a full animation library. Walk cycles, idle breathing, jumps, everything a game character needs.

The default walk animation looked almost right, but not quite. Kali's arms sat too close to her body and her head tilted at a slightly wrong angle. Both made sense for a generic humanoid but felt off on a round cartoon kitty. So we added runtime bone corrections in the game code: a shoulder offset that pushes the arms outward and a head rotation fix that straightens the tilt. Small tweaks, big difference. Without them she looked stiff and robotic. With them she looked like Kali again.

Playing the character in a browser

We dropped the rigged model into the Cinevva Engine. Third-person camera, WASD movement, collectibles scattered around, orbit camera when idle. Getting the animation blending right took iteration: crossfading between idle and walk, normalizing height, fixing the forward axis, tweaking bone offsets. Third-person camera behind the character closes the loop from sketch to something you can walk around.

Try it yourself. WASD to move.

What I'd tell someone doing this tomorrow

Lock one character look before you touch any generation tool. Every minute you spend getting that reference right saves an hour of chasing consistency later.

Write a tiny plot first. Then generate your start and end frames with the Image Generator. Keep reference images within API size limits. Use the T-pose from the same design system when you feed the 3D Model Generator.

Feed both frames to the Video Generator and let it interpolate. For the game mesh, rig the model through the platform and tweak bone offsets at runtime if the default animations don't quite fit your character's proportions.

Two years ago, this pipeline didn't exist. You'd need a team and a budget. Now you need a sketch and Cinevva's creative tools. I think that's a meaningful change in who gets to bring a character to life.

Cinevva tools used: Image Generator, Video Generator, 3D Model Generator, auto-rigging, and Cinevva Engine. Reflects early 2026.

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

We're building a multiplayer open world that runs entirely in the browser. No install, no app store, just a URL. The biggest risk up front was obvious: can a browser even render a persistent 3D world at playable frame rates while leaving headroom for gameplay, physics, and networking?

Most open world projects fail in a predictable order. First you get a nice concept. Then you get a pretty scene. Then you realize your frame budget is already gone before gameplay exists.

We wanted to answer the render budget question before investing in anything else. So Spike 1 skipped the pretty trailer and went straight to measuring.

Open Spike 1 in a new tab ↗ · View source

The setup was simple on purpose. A 512 meter terrain mesh, procedural height from layered sine noise with island falloff, a water plane, atmospheric fog, and 500 instanced objects. We used plain WebGL with Three.js, ACES tone mapping, and no shadows.

We didn't care how it looked. We cared whether the scene stayed stable while moving the camera through it.

Two things came out of this spike that shaped the whole project.

First, we confirmed we had real headroom on desktop if we kept the first pass disciplined. That gave us confidence to attempt the harder terrain architecture later.

Second, we created a baseline contract. Every next spike had to explain its cost relative to this scene. If a new feature looked good but cost too much, it did not get promoted.

That baseline discipline became critical later when we hit seam artifacts, mixed LOD transitions, and compute driven meshing. Without a stable reference, every bug looks bigger than it is.

In part 2 we move from rendering to input feel. Worker physics sounds great in architecture docs. It only matters if the character still feels immediate when you press a key.

Technology referenced in this chapter

Heightmap terrain. A 2D grid where each cell stores a single elevation value. The GPU displaces a flat mesh in the vertex shader to create the terrain surface. Heightmaps are compact (a 65x65 chunk is ~8 KB at 16-bit), GPU-friendly, and fast to render. The limitation is that they can't represent caves, overhangs, or any surface that folds back over itself. For background on heightmap constraints and what comes after them, see our landscape generation guide.

Three.js. The rendering library we used throughout this project. Three.js abstracts WebGL 2 (and later WebGPU) into a scene graph with cameras, lights, materials, and geometry objects. It provides InstancedMesh for rendering many copies of the same geometry in a single draw call, frustum culling, PBR materials, and post-processing. See Three.js on GitHub. For how Three.js fits into a browser open world stack, see our browser 3D tech guide.

InstancedMesh. A Three.js feature that renders N copies of the same geometry with a single draw call, each at a different position/rotation/scale. The per-instance transforms are stored in a matrix attribute buffer. This is how we rendered 500 objects in Spike 1 without 500 separate draw calls. For vegetation at scale, GPU-driven instanced culling takes this further. See our landscape guide on GPU vegetation culling.

Frame budget. At 60 fps, each frame has $\frac{1000\text{ms}}{60}\approx 16.7$ ms for everything: JavaScript logic, physics, rendering, and compositing. A "budget check" spike measures how much of that a baseline scene consumes, so the headroom left for everything you add later is $t_{\text{features}}=16.7-t_{\text{baseline}}$. If the baseline already eats 12 ms, only ~4.7 ms remains for gameplay, physics, and networking combined. This approach comes from AAA open world development where GTA V, Skyrim, and Elden Ring all use aggressive LOD and streaming to stay within fixed frame budgets.

Part 1 of 12.
Next: Part 2 - Worker physics and the input lag fear
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

If you build browser multiplayer long enough, you eventually get this argument.

"Physics in a worker is clean architecture. Physics on the main thread feels safer."

Both can be true. What matters is control feel and latency under real input.

Spike 2 was built to answer that with measurements, not opinions.

Open Spike 2 in a new tab ↗ · View source

We reused the Spike 1 terrain and integrated Rapier in a dedicated module worker. Input state was sent to the worker every frame, simulation stepped there, and authoritative position came back to the renderer.

The key metrics were input to visible movement latency and physics step timing. We also watched for jitter under normal movement, sprint bursts, and jump cadence.

The result was better than expected. With our message shape and cadence, the worker boundary did not dominate latency. Controls still felt immediate, which was the only thing players would care about.

One challenge from this phase was interpretation risk. After a successful result, teams often overgeneralize and assume the architecture question is closed forever. It is not. We only validated one concrete scenario and hardware profile. Later spikes still had to recheck assumptions when GPU and streaming pressure changed.

This spike also gave us a process upgrade. We started exposing timing telemetry in HUD by default for interactive spikes. That changed team conversations from "it feels off" to "this path added 1.2 ms."

In part 3 we cover the less glamorous experiments that prevented expensive surprises later. Broadcast load, mobile constraints, and behavior generation reliability.

Technology referenced in this chapter

Rapier. A physics engine written in Rust that compiles to WebAssembly for browser use. It handles rigid bodies, colliders, joints, character controllers, and raycasting at 2-3x native performance. For open worlds, Rapier provides player character controllers (walking on terrain, climbing steps, sliding on slopes), object collision, raycasting for interactions, and trigger volumes. See Rapier documentation and our browser 3D tech guide on physics.

Web Workers. Browser threads that run JavaScript (or Wasm) off the main thread. Physics simulation in a worker means a heavy world.step() call doesn't block rendering. The main thread sends input state to the worker each frame via postMessage and receives authoritative positions back. The latency penalty is the two message hops (~0.1-0.5 ms each on desktop). The benefit is that the render thread never stalls on collision detection. Transferable objects (ArrayBuffer transfer) eliminate copy overhead for large position arrays.

WebAssembly (Wasm). A binary instruction format that runs at near-native speed in browsers. Rapier, Havok, and Recast all compile to Wasm. The physics step in Rapier-Wasm is typically 0.5-2 ms for a few hundred bodies, compared to 5-15 ms for equivalent JavaScript. Wasm modules load as .wasm files fetched alongside the JavaScript glue code. See WebAssembly specification.

Input-to-visual latency. The time between a keypress and the resulting visual change on screen. For movement to feel "immediate," this needs to stay under ~80 ms. In a worker physics setup the chain is additive:

keydown event (main thread), postMessage to the worker and back ($2t_{\text{msg}}$), the physics step, the renderer applying the new position, then the next vsync. Each term is small on its own (~0.1-0.5 ms per message hop on desktop), but they stack, which is why we measured $L$ directly instead of trusting the architecture diagram.

Part 2 of 12.
Previous: Part 1 - We started by trying to break it
Next: Part 3 - The unflashy spikes that saved us
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

This part has fewer shiny screenshots and more architecture insurance.

After Spikes 1 and 2, we ran three risk checks that looked small but had product level impact.

First was broadcast fan out with Durable Objects. We tested multi client position distribution at game-like tick rates and tracked latency distribution, CPU per tick, and delivery integrity. If this had failed, we would have moved to early sharding instead of single island ownership.

Second was mobile constraint validation. Not a desktop preset renamed to mobile, but an explicit low-cost profile from the same baseline terrain.

Open the mobile profile in a new tab ↗ · View source

We reduced segment density, object count, render resolution pressure, and fog range. The question was simple. Can this world remain readable and responsive on mobile class constraints without rewriting the entire renderer.

Third was behavior generation reliability for creator workflows. We evaluated valid JSON rate, semantic correctness against expected primitives, and response latency. If this had failed, we would have moved to strict form based behavior authoring.

The key insight from this chapter is that these unflashy spikes changed architecture faster than visual spikes did. They set hard boundaries on network topology, mobile promises, and tool UX.

In part 4 we return to visible terrain work and test movement-time streaming behavior, not just static loading screenshots.

Technology referenced in this chapter

Cloudflare Durable Objects. Edge-deployed stateful serverless instances with built-in persistence and WebSocket support. Each Durable Object holds authoritative state for a world shard (or chunk). Players connect via WebSocket and receive position broadcasts from other players in the same shard. When the player moves to an adjacent chunk, they connect to that chunk's Durable Object. Durable Objects auto-persist state to disk and scale to thousands of concurrent instances. See Cloudflare Durable Objects docs and our browser 3D tech guide on multiplayer networking.

Spatial sharding. Dividing the world across server instances by geographic region. Each shard owns a rectangular area of the world grid. As player density shifts, shards can split or merge. Players near a shard boundary see both shards' content through cross-shard visibility queries. This is how EVE Online handles thousands of players in one universe.

WebSocket broadcast fan-out. Distributing real-time position updates from one server to many connected clients. Per-client downstream bandwidth scales linearly with the crowd you can see:

At game-like tick rates (20-30 Hz) each player generates $b_{\text{player}}\approx 800$ bytes/second of position data, so 200 players in view costs $200\times 800=160$ KB/s per client. The naive all-to-all server cost is worse, growing like $N^2$, which is exactly why relevance filtering (spatial interest management) caps $N_{\text{visible}}$ before it pushes to each connection within the tick budget. See our networking guide for delta compression and update frequency tradeoffs.

Mobile rendering constraints. Mobile GPUs have 1/5 to 1/10 the throughput of desktop GPUs, ~1 GB memory limit (vs 2-4 GB on desktop), and thermal throttling under sustained load. A mobile quality profile reduces segment density, object count, render resolution, draw distance, and shadow quality. The goal isn't parity with desktop but maintaining readability and responsiveness. See browser 3D performance numbers for real GPU benchmarks.

Part 3 of 12.
Previous: Part 2 - Worker physics and the input lag fear
Next: Part 4 - Streaming before fancy terrain
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Streaming is where "looks good" projects usually fall apart.

You can hide a lot in a still frame. You cannot hide a 40 ms hitch while crossing a chunk boundary.

We intentionally tested streaming before we built advanced terrain representation. That gave us clean signal on load and unload behavior.

Spike 6 validated neighborhood churn with simple chunk content.

Open Spike 6 in a new tab ↗ · View source

Then we moved to the real terrain path in Spike 11. Height chunk streaming with worker side decode and progressive refinement from 17 to 33 to 65 sample grids.

Open Spike 11 in a new tab ↗ · View source

The sequencing mattered more than we expected. If we had started directly with compressed height chunks, every hitch would have been ambiguous. Decode issue, texture upload issue, or geometry update issue. Spike 6 removed one uncertainty layer before Spike 11 added complexity.

A practical lesson from this chapter carried into later spikes. Upload stalls must be measured directly, not inferred from average FPS. Average FPS hides frame spikes, and frame spikes are what users actually feel.

In part 5 we move into the visual cost chapter where vegetation, terrain shaders, and cascaded shadows compete for the same frame budget.

Technology referenced in this chapter

Chunk-based streaming. The world is divided into a grid of independent chunks (typically 64x64 meters). As the player moves, chunks on the trailing edge unload while chunks on the leading edge stream in. This is how Skyrim's cell system works: a 5x5 grid of cells loaded around the player, swapping as they move. The browser version adds network latency to the equation, making predictive pre-fetching based on player velocity critical. See our streaming architecture guide.

Progressive heightmap refinement. Send terrain at low resolution first, then refine. The grid sizes aren't arbitrary: each level is a $(2^k+1)\times (2^k+1)$ grid, so $17=2^4+1$, $33=2^5+1$, $65=2^6+1$. The $+1$ keeps a shared sample on every boundary so neighbors line up, and each step roughly quadruples the sample count ($n^2$ grows as the side doubles). A 17x17 grid (the minimum for a 64m chunk at 4m spacing) is ~200 bytes compressed and renders a visible surface instantly. Then stream the 33x33 refinement, then the full 65x65 resolution. Each level adds samples without replacing previous data. This maps directly to geometry clipmap LOD rings where distant terrain uses low-resolution data and close-up terrain uses full resolution. See progressive chunk loading.

Delta encoding and compression. Heightmap data compresses well because adjacent cells have similar values. Delta encoding stores the difference between each cell and its predicted value (average of neighbors), clustering values near zero. Combined with zlib or brotli, a 65x65 chunk drops from 8.4 KB raw to 1-2 KB compressed. At reduced precision for distant chunks (8-bit instead of 16-bit): 0.5-1 KB. See terrain data compression.

Predictive pre-fetching. Loading chunks before the player arrives. The lead distance has to cover how far the player travels while a chunk loads, $d_{\text{prefetch}}=v\cdot t_{\text{load}}$, so it scales with speed: at walking speed (5 km/h) pre-fetch 2 chunks ahead (128m), at running speed (15 km/h) pre-fetch 4. The load ring shifts with velocity direction. A priority queue sorts pending requests by urgency and cancels requests for chunks the player has moved away from. See predictive pre-fetching.

Part 4 of 12.
Previous: Part 3 - The unflashy spikes that saved us
Next: Part 5 - Budgeting the pretty stuff
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

This was the chapter where visual ambition met arithmetic.

We split rendering cost into separate spikes because bundled results are hard to diagnose. If you turn everything on at once, you only learn that the frame is slow. You don't learn which feature ate the budget.

Spike 7 targeted vegetation density and animation cost. The approach was runtime scattering from 32x32 density maps per terrain chunk, feeding large InstancedMesh sets. Each grass blade and shrub cluster got vertex-shader wind driven by a scrolling noise texture. The key number we watched wasn't triangle count but draw call overhead and vertex throughput on mid-range GPUs. We found that batching instances into fewer meshes mattered more than reducing per-blade polygon count.

Open Spike 7 in a new tab ↗ · View source

Spike 8 pushed terrain material complexity. Multi-layer blending weighted by slope angle and altitude, optional triplanar projection for cliff faces, and per-layer normal maps. The shader was doing slope-based splatting with four texture layers, each needing a diffuse and normal sample. That's $4\times 2=8$ texture fetches per fragment before you add any lighting, and the count grows linearly with layers, so a fifth layer means 10 fetches every pixel. We profiled on integrated Intel GPUs specifically to find the floor. The takeaway was that triplanar projection on vertical surfaces was worth the cost, but adding a fifth splat layer wasn't.

Open Spike 8 in a new tab ↗ · View source

Spike 9 focused on cascaded shadow map cost under realistic terrain and object load. CSM with three cascades was baseline. We tested with low-angle sun positions specifically because that's where cascade pressure gets worst. The far cascade covers a huge frustum slice, and shadow detail is set by texel density, $\rho \approx \frac{R^2}{A}$ (a shadow map of resolution $R$ stretched over ground area $A$). One map over the whole view distance makes $A$ enormous and $\rho$ collapses. Cascades fix this by splitting the frustum so each slice gets its own $R\times R$ map over a small $A$, keeping $\rho$ roughly constant from near to far. We measured the GPU time difference between two and four cascades, then between 1024 and 2048 shadow map resolution. The result was that three cascades at 1024 gave us acceptable contact shadows near the camera without exceeding 2ms of GPU time on our target hardware.

Open Spike 9 in a new tab ↗ · View source

The hard part in this phase was product discipline. Some effects looked excellent and still had to be constrained because they consumed too much of the frame budget relative to their visual impact.

Our rule became simple. A feature moves forward only if it can explain its cost with measured frame-time data.

That sounds obvious. It's not common in fast prototype cycles where everyone is excited about the next visual win. Keeping this rule early made architecture decisions around clipmaps and volumetric zones much cleaner later, because we already knew the per-feature cost of everything competing for the same 16ms.

In part 6 we hit the first major terrain architecture pivot with geometry clipmaps.

Technology referenced in this chapter

InstancedMesh and GPU vegetation. Three.js's InstancedMesh renders N copies of the same geometry with one draw call. For vegetation, a density map (32x32 per chunk) drives runtime scattering of grass blades and shrub clusters into instance buffers. Wind animation runs in the vertex shader using a scrolling noise texture. At scale, WebGPU's ComputeInstanceCulling eliminates off-screen and distant instances before rasterization, and IndirectBatchedMesh packs multiple vegetation types into a single buffer drawn with multi-draw indirect. See our landscape guide on GPU vegetation culling.

Triplanar mapping. Standard UV-mapped textures stretch on steep slopes because UV coordinates compress. Triplanar mapping projects textures along all three axes (X, Y, Z) and blends based on the surface normal. Cliff faces get the X or Z projection (no stretching), flat ground gets the Y projection. The blending is smooth and automatic with no UV unwrapping required. For PBR terrain, the same blending weights apply to albedo, normal, roughness, and ambient occlusion channels. See triplanar mapping details.

Slope and altitude-based material splatting. Instead of hand-painted splat maps, materials are assigned procedurally in the fragment shader based on terrain properties. Flat ground at low altitude gets grass, steep slopes get rock, high altitude gets snow (only on surfaces flat enough for accumulation), near sea level gets sand. The transitions use smoothstep for smooth blending. In our implementation, each terrain chunk evaluates four texture layers with diffuse and normal samples per layer, resulting in eight texture fetches per fragment before lighting. See slope and altitude material assignment.

Cascaded Shadow Maps (CSM). CSM splits the camera's view frustum into 3-4 distance ranges (cascades). Each cascade renders a shadow map from the sun's perspective at a resolution matched to its distance. Close cascades get high-resolution shadows (detailed contact shadows under trees and buildings), far cascades get lower resolution (broad mountain shadows). The terrain shader samples all cascades and selects the appropriate one per fragment. Performance cost: 3-4 cascades at 1024x1024 add ~0.5-1 ms for shadow map rendering plus ~0.2-0.3 ms for sampling. See shadows for terrain.

Part 5 of 12.
Previous: Part 4 - Streaming before fancy terrain
Next: Part 6 - Clipmaps changed the plot
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Before Spike 10, our mental model was still "bigger world means more geometry." After Spike 10, the model became "constant geometry budget, camera-centered ring updates." That shift changed the project trajectory.

The idea behind geometry clipmaps is straightforward. You render terrain as a set of concentric rings centered on the camera. The innermost ring has the highest vertex density. Each ring $k$ outward doubles the vertex spacing, $s_k=s_0\cdot 2^k$, so it covers $4\times$ the ground area of the ring inside it.

That doubling is the whole trick. View distance grows geometrically with the number of rings, $d_{\text{view}}\approx s_0\cdot 2^L$, while the vertex cost grows only linearly:

for $L$ rings of $N\times N$ vertices each. Doubling how far you can see costs one more ring, not four times the geometry. The triangle count stays roughly constant no matter the world size, because you always render the same $L$ rings at the same resolution.

Open Spike 10 in a new tab ↗ · View source

The practical trick was geomorphing at ring boundaries. When a vertex transitions from one LOD ring to the next, its height has to blend smoothly between the high-res and low-res sample. Without that, you get visible pops every time the camera moves and rings shift. We handled this with a blend factor based on the vertex's distance to the ring edge, interpolating height in the vertex shader:

where $d$ is the vertex's distance from the camera. Inside the ring ($d\le d_{\text{near}}$) the vertex uses its full-resolution height; by the time it reaches the next ring ($d\ge d_{\text{far}}$) it has already migrated to the coarse height that ring will use, so there's nothing left to pop.

One subtle lesson came from camera movement testing. It's easy to judge clipmaps in static screenshots and miss transition artifacts. We spent time running constant-speed traversals through ring boundaries and watching for temporal noise. Screenshots lied. Motion told the truth.

This spike also gave us a clean architectural boundary. Near-field terrain could become dynamic and expensive over time, with volumetric editing, higher material complexity, and physics interaction. Far-field terrain could stay stable, predictable, and cheap. That separation became the backbone of every architectural decision from this point forward.

If you're evaluating clipmaps for your own project, test stress loops, not beauty shots. Long traversal paths, changing camera altitude, and repeated boundary crossings are what expose the real problems.

In part 7 we add volumetric meshing and move from "terrain as a surface" to "terrain as editable volume." That was the point where this project stopped being a renderer and started becoming a world editor.

Technology referenced in this chapter

Geometry clipmaps. Introduced by Losasso and Hoppe at SIGGRAPH 2004 (paper), geometry clipmaps render terrain as concentric square rings centered on the camera. Each ring is twice the area of the previous one at half the vertex resolution. The total vertex count is constant: roughly $N^2\cdot L$. With $N=256$ and $L=8$ levels, that's ${256}^2\times 8\approx \mathrm{524,000}$ vertices regardless of world size. The CPU updates heightmap data for each ring as the camera moves. The vertex shader reads height from a texture and displaces the flat grid. See our landscape guide on geometry clipmaps and GPU Gems 2, Chapter 2.

Geomorphing. The biggest visual artifact in terrain LOD is popping: vertices suddenly jump when a patch switches LOD level. Geomorphing eliminates this by blending vertex positions between LOD levels over a transition zone. Each vertex stores both its current-LOD height and its coarser-LOD height. A morph factor based on camera distance smoothly interpolates between them: morphedHeight = mix(fineLodHeight, coarseLodHeight, smoothstep(lodNear, lodFar, distance)). The transition zone is typically the outer 20% of each ring. At normal camera speeds, the transition is invisible. See geomorphing details.

CDLOD (Quadtree-Adaptive Clipmaps). An improvement on fixed-ring clipmaps by Strugar (2014, paper). Instead of concentric rings with uniform resolution, CDLOD uses a quadtree that adapts to terrain complexity. Flat areas use coarse nodes, while areas with high detail (cliffs, ridges) get finer subdivision. This matters for creator worlds where different chunks have vastly different complexity. See CDLOD in our landscape guide.

Part 6 of 12.
Previous: Part 5 - Budgeting the pretty stuff
Next: Part 7 - Marching cubes and the first real caves
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Heightmaps are great until you need overhangs.

The moment you want carved tunnels, floating rock lips, or cave ceilings, a pure heightfield pipeline starts blocking you. A heightmap stores one Y value per XZ coordinate. It's physically incapable of representing any surface that folds back over itself. We needed a volumetric representation.

Spike 12 implemented marching cubes on the GPU using WebGPU compute shaders. The algorithm evaluates a signed distance field (SDF) on a 3D grid and extracts a triangle mesh at the zero-crossing surface. Each cell has 8 corners, each either inside or outside the surface, which gives $2^8=256$ possible sign patterns. A lookup table maps each pattern to a set of triangles. Vertices sit on the cell edges at the point where the field crosses zero. For an edge between corners $a$ and $b$ with field values $f_a$ and $f_b$, linear interpolation places the vertex at

which is the fraction along the edge where the field hits zero. Because $f_a$ and $f_b$ have opposite signs on a crossing edge, $t$ always lands in $[0,1]$. We ran this on four active 64-cubed chunks simultaneously and tested animated SDF edits with per-frame remesh.

Open Spike 12 in a new tab ↗ · View source

The first win was confidence in the compute pipeline itself. A single dispatch could evaluate the SDF, classify cells, and emit vertices into a GPU buffer without any CPU readback. The second win was discovering how fast "it works" turns into artifact hunting. Missing triangles were rarely a marching cubes theory problem. They were table index mismatches, incorrect draw ranges reading past the active vertex count, or edge-case interactions near chunk boundaries where neighboring SDF samples weren't available.

This spike forced us to think in zones. Near the camera, you want volumetric freedom so players can carve, dig, and see caves. Far from the camera, you want clipmap efficiency where a flat heightmap is cheaper and perfectly adequate. That duality became the backbone of the architecture we kept refining from Spike 13 onward.

One of my favorite debugging moments was the wireframe toggle while edits were running. Watching topology form and dissolve in real time made quality tradeoffs immediately visible. You could see where vertex density was high enough, where it got too coarse, and exactly where LOD transitions would eventually need Transvoxel support to avoid cracks.

In part 8 we cover the integration challenge. Keeping raw compute-driven meshes and Three.js scene graph logic in one stable rendering pipeline was harder than the isolated demo suggested.

Technology referenced in this chapter

Marching cubes. An algorithm for extracting a triangle mesh from a 3D scalar field (Lorensen and Cline, 1987). Each cell in a regular 3D grid is classified by sampling the field at its 8 corners. The sign pattern produces a case index (0-255), and a lookup table maps each case to a set of triangles. Vertices are placed on grid edges by interpolating between the two corners. The algorithm is embarrassingly parallel since each cell processes independently, making it ideal for GPU compute. See our landscape guide on SDFs and marching cubes.

Signed Distance Fields (SDFs). A volumetric representation that stores, at every point in 3D space, the signed distance to the nearest surface. Positive values are outside, negative are inside, and the zero-crossing is the surface. SDFs can represent arbitrary 3D shapes: caves, arches, overhangs, and floating geometry that heightmaps can't express. Editing is natural set algebra on the field. Adding material (union of two shapes) is $d=min(d_1,d_2)$, removing (digging) is $d=max(d_1,-d_2)$ with the carve shape negated, and a smooth blend uses a soft minimum such as

where $k$ controls the blend radius. As $k\to 0$ this collapses back to a hard $min$. See SDF terrain representation.

WebGPU compute shaders. GPU programs that run general-purpose computation, not tied to the rasterization pipeline. A compute shader dispatches workgroups of threads that execute in parallel. For marching cubes, each thread processes one grid cell: sample the SDF, classify the cell, look up triangulation, interpolate edge vertices, and append to a mesh buffer using atomic counters. No CPU readback is needed because the output buffer is used directly as vertex data for rendering. Will Usher's webgpu-marching-cubes demonstrates real-time 256^3 grid processing in the browser. See our landscape guide on WebGPU-driven LOD.

Hybrid heightmap + SDF architecture. The practical approach for browser terrain: heightmaps cover the entire world (cheap, compact), while SDF volumes exist only in chunks that need caves, overhangs, or creator-carved features (5-10% of chunks). Near the camera, volumetric freedom allows carving and caves. Far away, heightmaps provide efficient flat terrain. See hybrid terrain representation.

Part 7 of 12.
Previous: Part 6 - Clipmaps changed the plot
Next: Part 8 - Integration without losing our baseline
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Integration is where projects get messy. You have working pieces in isolation. You connect them and suddenly every bug looks like it could be anywhere.

Spikes 13 and 14 were our answer to that trap. Spike 13 established a clean Three.js WebGPU baseline. Just a renderer, a scene, a camera, and a simple mesh. No terrain, no compute, no effects. We confirmed that Three.js's WebGPU backend initialized correctly, that the render loop was stable, and that TSL (Three.js Shading Language) node materials worked as expected. Only after that checkpoint passed did we start adding layers.

Open Spike 13 in a new tab ↗ · View source

Spike 14 was incremental hardening. We added one capability at a time: first camera controls, then lighting, then the compute-generated mesh from the marching cubes pipeline, then buffer plumbing to feed GPU output directly into Three.js geometry attributes. After each addition, we verified that the previous layer still behaved correctly.

Open Spike 14 in a new tab ↗ · View source

That sounds slow. It was slow for exactly one day, and it saved us multiple days soon after when seam logic and policy switching got complicated.

The specific category of bug that justified this discipline was hairline artifacts. Thin slivers that looked like geometry corruption but were actually stale data. The compute shader would write N vertices into a buffer, but the draw call would still be configured to render N+M vertices from the previous frame. Those extra vertices contained garbage from the old dispatch. The visual result was flickering razor-thin triangles that appeared and vanished unpredictably.

You don't beat that class of bug with intuition. You beat it with controlled deltas where you know exactly what changed between the last working state and the current broken state.

The WebGPU integration also taught us about buffer lifecycle. GPU buffers in WebGPU are immutable once mapped for a specific usage. If you need to resize a vertex buffer because the marching cubes output grew, you have to create a new buffer and update the binding. There's no realloc. Getting that lifecycle right, destroying old buffers without racing against in-flight GPU work, required explicit fence management that doesn't exist in WebGL.

In part 9 we move into Transvoxel seam work. That chapter starts with a scaffold on purpose. By this point we had fully internalized the lesson that rushing integration produces mysteries, and controlled setup produces debuggable problems.

Technology referenced in this chapter

WebGPU. The successor to WebGL, providing low-level GPU access in the browser with compute shaders and indirect rendering. WebGPU's two critical features for open worlds: compute shaders enable GPU-side terrain generation, foliage placement, and culling; indirect rendering lets the GPU decide what to draw based on compute output, eliminating CPU bottlenecks in dense scenes. Available in Chrome, Edge, and Firefox on desktop. See WebGPU as a performance unlock.

Three.js Shading Language (TSL). Three.js's node-based shader system that replaces raw GLSL/WGSL with composable JavaScript expressions. TSL nodes like texture(), positionWorld, smoothstep(), and fog() build a shader graph at runtime that compiles to the appropriate backend (WebGL GLSL or WebGPU WGSL). TSL makes it possible to write material logic once and target both renderers. The node graph is evaluated per-frame, so dynamic uniforms and conditional branching work naturally.

GPU buffer lifecycle in WebGPU. WebGPU buffers are created with specific usage flags (VERTEX, STORAGE, COPY_DST, etc.) and can't be resized after creation. If a marching cubes dispatch produces more vertices than the buffer can hold, you must create a new buffer, update the binding, and destroy the old one. Destroying a buffer that's still referenced by an in-flight GPU command causes errors. Explicit fence management (via device.queue.onSubmittedWorkDone()) ensures the old buffer isn't destroyed until the GPU finishes using it. This lifecycle discipline doesn't exist in WebGL, where the driver manages memory implicitly.

Incremental hardening. A process discipline for integration: establish a known-good baseline, add one capability at a time, and verify the previous layer still works after each addition. This approach is slower for one day and saves days during later debugging because each regression can be traced to a specific, controlled change. The baseline-then-increment pattern is common in AAA open world development where systems are integrated in a specific order to manage risk.

Part 8 of 12.
Previous: Part 7 - Marching cubes and the first real caves
Next: Part 9 - Transvoxel started with a scaffold
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Seams are where confidence goes to die.

Everything can look stable until two resolutions meet. A chunk at LOD 0 sits next to a chunk at LOD 1. Their meshes are generated independently. Where they share a boundary, the vertex positions don't match because the lower-resolution chunk has half the grid density. The result is visible cracks, T-junctions, and flickering edges.

The Transvoxel algorithm solves this by generating special transition cells along the boundary face between two chunks at different resolutions. These cells sample from both the high-res and low-res grids simultaneously and produce triangles that stitch the two surfaces together. The algorithm uses its own lookup tables, separate from the regular marching cubes tables, with 512 transition cell cases.

We had enough integration scars by this point to know better than to rush the implementation.

Spike 15 had one job: build a seam test rig we could trust before touching the full algorithm. We set up a controlled environment where two chunks of known SDF data sat side by side at different resolutions, with visualization controls to toggle the main mesh, the seam mesh, wireframe, and normals independently.

Open Spike 15 in a new tab ↗ · View source

Once the test rig was stable, Spike 16 validated table-driven transition cell generation on a single face. We picked one axis-aligned face (+X boundary), implemented the transition cell evaluation for that face only, and compared the output against reference data from the Transvoxel paper.

Open Spike 16 in a new tab ↗ · View source

We tested one face at a time on purpose, because transition table wiring has many independent failure modes. Case index computation depends on sampling the correct vertices from both grids. Vertex indexing within a transition cell uses a different numbering scheme than regular marching cubes cells. Winding order has to be consistent with the main mesh or backface culling will eat your seam triangles. If you test all six faces at once, every symptom looks random. If you test one face thoroughly, you get meaningful, debuggable failures.

Another subtle win from this phase was tooling investment. We built visibility toggles, seam-only rendering, and color-coded LOD indicators early. Those controls felt like overhead at the time. Later, when corner cases got ugly, they paid for themselves over and over because we could isolate exactly which seam cells were misbehaving.

By the end of this chapter we weren't "done with seams." We were in a position where seam bugs could be reasoned about instead of feared.

In part 10 the real roller coaster starts. Mixed LOD corners, winding flips, partial overdraw ghosts, and those moments where you're sure the algorithm is wrong and then discover the bug is a draw range reading past the active vertex count.

Technology referenced in this chapter

The Transvoxel algorithm. Designed by Eric Lengyel (transvoxel.org), Transvoxel solves the hardest problem in volumetric terrain LOD: seams between chunks at different resolutions. When a high-res chunk sits next to a low-res chunk, the marching cubes meshes don't align at the boundary, producing visible cracks. Transvoxel inserts special transition cells along boundary faces that bridge the resolution difference with additional triangles matching both sides. The algorithm uses its own lookup tables (separate from regular marching cubes) with 512 transition cell cases, reduced to 73 equivalence classes. It's patent-free and has been used in shipped games (Space Engineers, Astroneer). See our landscape guide on Transvoxel.

Transition cells. Special cells generated at the face between two LOD levels. Unlike regular marching cubes cells that sample 8 corners from one grid, transition cells sample from both the high-res and low-res grids simultaneously. The high-res face has $3\times 3=9$ sample points, while the low-res face has $2\times 2=4$. Those 9 samples are what give the algorithm its $2^9=512$ raw cases, which collapse to 73 distinct triangulations once you fold out rotations and reflections. The cell classification and triangulation use dedicated tables that produce triangles connecting vertices at both resolutions. The vertex numbering scheme is different from regular MC cells, which is a common source of implementation bugs.

LOD transition seams. The boundary between two mesh resolutions where topology mismatch causes visual artifacts. Without stitching, a LOD 0 chunk (1m grid) next to a LOD 1 chunk (2m grid) produces T-junctions: the fine mesh has vertices along the boundary that the coarse mesh doesn't share, causing cracks where light bleeds through. Transvoxel, geomorphing, and skirt geometry are three approaches to fixing these seams. For volumetric terrain, Transvoxel is the standard solution because geomorphing only works for heightmaps. See LOD for volumetric terrain.

Part 9 of 12.
Previous: Part 8 - Integration without losing our baseline
Next: Part 10 - Seam chaos and the corner boss fight
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

If the earlier parts felt methodical, this chapter felt like combat.

Spikes 17 through 22 were our corner-case era. Dual-LOD marching cubes, heightmap-to-MC boundary seams, mixed-resolution corner chunks where three or four LOD levels meet, GPU seam generation, and fallback mode behavior. Each spike addressed a specific failure scenario we'd encountered or anticipated.

Spike 17 tested dual marching cubes with two LOD levels active simultaneously. The challenge was that a single chunk's neighbors could be at different resolutions on different faces. The transition cell logic from Spike 16 worked for one face at a time, but when a chunk needed transition cells on multiple faces, the vertex buffer management got complicated. Each face's transition cells had to be generated and appended without overwriting the others.

Open Spike 19 in a new tab ↗ · View source

The first repeated villain was winding order. Several times we thought we had topology problems, then found orientation problems. Backface culling was eating valid seam triangles because the winding was flipped relative to the main mesh. Same root cause, different visual symptom depending on camera angle. The fix was enforcing a consistent winding convention in the transition cell emission code and verifying it with a double-sided material toggle.

The second villain was false confidence from partial correctness. A seam could look perfect from one camera angle and break when LOD roles swapped between higher and lower resolution chunks. The transition cell is asymmetric. It samples from the high-res side and the low-res side differently. If you get the "which side is high-res" logic backwards for one configuration, you only see the bug when the camera moves to a specific position.

Then came one of our favorite recoveries. We were chasing a seam cutoff artifact on heightmap tiles and blaming the transition logic. Burned two days on it. The real culprit was stale overdraw. Higher-resolution geometry from a previous frame was still living in the buffer tail after the chunk downscaled to a lower LOD. The draw range was still set to the old, larger vertex count. Once we clipped the draw range to the active vertex count reported by the compute shader's atomic counter, the "mystery seam issue" disappeared.

That was a great reminder that rendering bugs often masquerade as meshing bugs. The geometry was correct the whole time. The draw call was just reading past the end of valid data.

By Spike 22 we were testing hybrid fallback where chunks could switch from marching cubes to heightmap mode under specific conditions, like when the chunk contains no volumetric edits and sits far enough from the camera. This gave us a more practical path than an all-or-nothing policy. Near-field edited chunks use MC for volumetric freedom. Far-field unedited chunks use heightmaps for efficiency.

Open Spike 22 in a new tab ↗ · View source

This chapter was the steep drop of the roller coaster. Frustrating and productive at the same time. Many of the individual fixes were small, sometimes a single line changing a comparison operator or an offset. But the understanding they produced about how LOD transitions, buffer management, and draw ranges interact wasn't small at all.

In part 11 we cover the stabilization layer that came after the chaos: policy-based chunk modes and the transition from reactive bug-fixing to explicit system rules.

Technology referenced in this chapter

Dual-LOD marching cubes. Running marching cubes at two resolution levels simultaneously, with transition cells stitching the boundary. The challenge is that a single chunk's neighbors can be at different resolutions on different faces, requiring independent transition cell generation per face. Each face's transition cells are appended to the vertex buffer without overwriting the others. Atomic counters track the total active vertex count across all faces.

Winding order. The vertex order within each triangle determines which side is the "front" face. Consistent winding (typically counter-clockwise when viewed from outside) is required for backface culling. When transition cells emit triangles, the winding must match the main mesh's convention. Getting it backwards causes backface culling to eat valid seam triangles, which looks like missing surfaces from certain camera angles. A common debugging technique is toggling side: THREE.DoubleSide on the material to confirm whether artifacts are winding issues or genuine topology gaps.

Heightmap-to-MC fallback. A hybrid chunk mode where far or unedited chunks use heightmap terrain (cheap, flat surface) while near or edited chunks use marching cubes (volumetric, supports caves). The fallback decision depends on distance from camera and whether the chunk contains SDF edits. The seam between a heightmap chunk and an MC chunk requires its own transition geometry, similar to Transvoxel but bridging two different representations rather than two LOD levels. See hybrid heightmap + volumetric overlays.

Draw range and atomic counters. In GPU-driven mesh generation, the compute shader writes vertices into a buffer and increments an atomic counter to track how many vertices were emitted. The draw call must use this counter as the vertex count, not the buffer capacity. If the draw range isn't clipped to the active count, stale vertices from previous frames (still living in the buffer tail) produce ghost geometry: thin slivers and flickering triangles that look like topology errors but are actually rendering artifacts from reading past valid data.

Part 10 of 12.
Previous: Part 9 - Transvoxel started with a scaffold
Next: Part 11 - Policy mode, not hardcoded mode
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

After the seam chaos chapter, we needed to stop reacting and start governing.

Spike 23 replaced ad-hoc behavior with explicit policy rules. Instead of chunks doing whatever their local state suggested, a central policy system now made the decisions. Which LOD level does this chunk get? Is it rendered as heightmap or marching cubes? Does it need transition cells, and on which faces? The answers came from a policy function that evaluated distance to camera, edit history, and neighbor resolution states.

Open Spike 23 in a new tab ↗ · View source

The distance-based LOD assignment used concentric rings around the camera, similar to the clipmap concept but applied to the chunk grid. Ring 0 chunks get full-resolution MC. Ring 1 gets half-resolution MC. Ring 2 and beyond get heightmap mode. The adjacency constraint was critical: for any two neighboring chunks we require $|L_i-L_j|\le 1$. The resolution ratio across a face is $2^{|L_i-L_j|}$, and the Transvoxel transition tables are defined for the 2:1 case only ($|L_i-L_j|=1$). A jump of 2 levels would need a 4:1 transition the tables can't express, so the policy forces the lower-detail chunk to upgrade until the constraint holds.

The HM/MC switching logic checked each chunk's edit bitmap. If a chunk had any volumetric edits (caves, tunnels, terrain sculpts), it stayed in MC mode regardless of distance. Unedited chunks could drop to heightmap mode when they moved far enough away. This hybrid approach gave us volumetric freedom where it mattered and efficiency where it didn't.

This spike looked smaller from the outside than some earlier ones. In practice it was a major quality-of-life improvement for development.

When your system can explain why a chunk switched mode, you spend less time guessing. We added color-coded overlays: green for heightmap chunks, blue for MC chunks, orange for transition-active faces. When seam visibility has dedicated render controls, visual debugging ambiguity drops. When draw ranges are explicitly tied to active vertex counts from the policy system, stale geometry ghosts stop wasting your afternoon.

We also overhauled camera behavior in this spike. Earlier spikes had simple orbit controls fine for screenshots but useless for reproducing bugs. Spike 23 added WASD fly camera with configurable speed, altitude lock toggle, and position readout. That sounds minor. It meant the difference between "I saw a bug somewhere near that ridge" and "the bug appears at position (142, 12, -67) facing northwest."

The key insight from this chapter is that policy didn't reduce complexity. It organized complexity. The same number of edge cases existed. But now each edge case had a name, a trigger condition, and a place in the code where you could set a breakpoint. That's a different kind of win, and it's what determines whether a system can keep evolving or collapses under its own weight.

By the end of Spike 23, we had a near-field behavior layer that was predictable enough to connect to a far-field clipmap ring strategy without constant fear of interaction bugs.

In part 12 we cover Spike 24, where ring transitions, skybox fog, and Three.js version-level shader integration close out this chapter of the project.

Technology referenced in this chapter

Distance-based LOD policy. A central function that assigns LOD level and rendering mode to each chunk based on distance to camera, edit history, and neighbor states. Concentric distance rings determine the base LOD: ring 0 = full-res MC, ring 1 = half-res MC, ring 2+ = heightmap mode. The policy function runs per frame as the camera moves and triggers chunk transitions. This replaces ad-hoc per-chunk decisions with a predictable, debuggable rule system. See GPU-driven LOD selection for the compute shader equivalent.

Adjacency constraints. The Transvoxel algorithm handles 2:1 resolution ratios only. If two neighboring chunks differ by more than one LOD level (e.g., LOD 0 next to LOD 2), the transition tables can't produce valid seam geometry. The policy system enforces this by upgrading the lower-detail chunk when the LOD difference exceeds 1. This constraint propagation can cascade: upgrading one chunk may force its neighbors to upgrade as well. The implementation is a simple iterative pass that converges in 2-3 iterations for typical grid configurations.

Edit bitmap for mode selection. Each chunk maintains a bitmap recording whether it contains volumetric SDF edits (caves, tunnels, sculpts). Chunks with any edits stay in marching cubes mode regardless of distance, preserving the creator's modifications. Unedited chunks drop to heightmap mode when far enough from the camera, saving compute and memory. The bitmap is a single flag per chunk but can be extended to track edit density for more granular mode decisions.

Debug visualization overlays. Color-coded chunk rendering where green = heightmap mode, blue = MC mode, orange = transition-active faces. Per-chunk overlays with LOD level numbers, mode labels, and wireframe toggles. These are development tools, not shipped features, but they pay for themselves repeatedly when debugging LOD transitions and seam artifacts. Combined with a WASD fly camera that reports exact world position, they turn "I saw a bug somewhere" into "the bug appears at (142, 12, -67) with this LOD configuration."

Part 11 of 12.
Previous: Part 10 - Seam chaos and the corner boss fight
Next: Part 12 - Rings, sky fog, and what we would do again
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Spike 24 was supposed to be "add clipmap rings to the terrain." It became a full finale that touched rendering, shaders, module infrastructure, and visual integration all at once.

The core terrain task was generating concentric clipmap rings in the vertex shader. Each ring is a flat grid mesh centered on the camera, with vertices displaced by heightmap samples. The inner ring uses full resolution. Each subsequent ring doubles the vertex spacing and covers a larger area. The tricky part is the boundary between rings: where a high-resolution ring meets a low-resolution ring, edge vertices on the finer mesh need to snap to the midpoint of the coarser mesh's edge. We did 2:1 edge morphing by detecting boundary vertices (those whose grid coordinate is odd along the ring edge) and snapping their height to the midpoint of their two even neighbors, $h=\frac{1}{2}(h_{\text{left}}+h_{\text{right}})$. That's exactly the point the coarse ring's single edge would sit at, so the fine and coarse edges describe the same line. This produces watertight seams without transition geometry.

Open Spike 24 in a new tab ↗ · View source

Then came the fog and sky integration. We wanted distant terrain to fade into the actual sky color, not a flat constant. That meant the fog shader needed to know what color the sky would be in the direction of each fragment. We loaded an equirectangular HDR skybox texture and sampled it in the fragment shader using the view direction from camera to fragment, converted to equirectangular UV coordinates via TSL's equirectUV node. The fog factor was distance-based using positionView.z.negate() for camera-space depth, blended with smoothstep between a near and far distance.

Module wiring turned out to be more annoying than any of the geometry. We upgraded to Three.js 0.183.1, which restructured the build outputs. The three/tsl import needed to resolve to three.tsl.js, and TSL internally imported three/webgpu as a bare specifier. Both mappings had to be explicit in the HTML import map. Missing either one produced cryptic "does not provide an export" or "failed to resolve module specifier" errors with no indication of which mapping was wrong. Once both were in the import map, the shader graph loaded correctly.

We also had a skybox orientation issue where the texture rendered upside down. The fix was flipY = true on the equirectangular texture, which is the Three.js default for loaded textures but was set to false in our initial code.

The original fog implementation sampled the sky at a near-constant direction, producing a thin horizon-colored band instead of a natural gradient. The fix was computing the actual camera-to-fragment world direction per pixel using positionWorld.sub(cameraPosition).normalize() and passing that into equirectUV for the fog color lookup. This made terrain fragments fade into the sky color that's actually behind them, which looks correct from any camera angle.

Underneath all the individual fixes, the core outcome held. We now have a terrain system that combines near-field volumetric editing (marching cubes with Transvoxel seams), mid-field heightmap chunks, and far-field clipmap rings, all governed by a policy layer that decides mode, LOD, and transition behavior.

If I had to name the patterns I'd repeat on the next project, they'd be these:

Start with risk spikes before feature work. Spike 1 killed the "can we even render fast enough" question before we invested in content pipelines.

Freeze known-good baselines before integration jumps. Spikes 13 and 14 saved us days of bisecting regressions.

Force policy and observability before optimization marathons. Spike 23 turned mystery bugs into named conditions with trigger rules.

Test under motion, not screenshots. Clipmap pops, seam flicker, and streaming hitches all hide in still frames.

Measure frame-time cost per feature, not average FPS. Averages hide the spikes that users actually feel.

And publish the messy parts. The wrong turns, the stale-buffer ghost hunts, the two days blaming transition logic when the draw range was wrong. Those are the parts people can actually learn from.

External reality check: Vuntra City devlogs

After finishing this series, we reviewed the @VuntraCity devlogs as an external implementation check against our own open-world assumptions. It's a native UE5 project, not a browser stack, but the system patterns map well enough that the comparison is useful.

The first signal is that traversal speed has to be treated as a streaming control, not just gameplay. In Vuntra City, high-speed transit is intentionally routed above most interiors, and detail range scales with movement speed to avoid spawn churn and stalls (transport system, performance techniques). That matches our policy-layer direction: movement mode should directly influence chunk radius, interior activation, and allowed work per frame.

The second signal is architecture. Their maps and address system required separating world topology from rendered objects so global queries can run for unloaded regions (maps and addresses). That's the same separation we need in browser for world search, quest routing, moderation scans, and POI indexing without forcing render-bound data paths.

The third signal is simulation tiering. Their million-NPC design keeps coarse schedule state cheap and global, then spends expensive behavior budget only near the player (million-NPC overview, system deep dive). That reinforces our own AOI-first simulation model, where near-field fidelity and far-field determinism are separate concerns with separate budgets.

And the fourth signal is design quality, not raw scale. Their strongest exploration moments come from weighted distributions, rare outliers, and diegetic navigation clues instead of constant UI overlays (procedural environment notes, no minimap loop). For us, this is a reminder that technical systems should be tuned to produce discoverable variation, not just maximal throughput.

Technology referenced in this chapter

Clipmap ring geometry. Each ring is a flat grid mesh centered on the camera with vertices displaced by heightmap samples. The inner ring uses full resolution. Each subsequent ring doubles vertex spacing and covers a larger area. The tricky part is the boundary: where a high-res ring meets a low-res ring, edge vertices on the finer mesh snap to the midpoint of the coarser mesh's edge. The technique originates from Losasso and Hoppe's SIGGRAPH 2004 paper (PDF) and is detailed in GPU Gems 2, Chapter 2. See our landscape guide on geometry clipmaps.

2:1 edge morphing. At the boundary between two clipmap rings, the finer ring has vertices at positions the coarser ring doesn't share. Boundary vertices whose grid coordinate is odd along the ring edge are detected and their height is interpolated between the two neighboring even vertices. This produces watertight seams without dedicated transition geometry. The interpolation runs in the vertex shader: morphedHeight = mix(heightLeft, heightRight, 0.5) for boundary vertices, using the same geomorphing framework described in our guide.

Equirectangular skybox mapping. A single 2D image that maps the full sphere of sky directions using longitude-latitude projection. The horizontal axis covers 0-360 degrees, the vertical axis covers 0-180 degrees. A normalized view direction $\hat{d}=(d_x,d_y,d_z)$ converts to UV coordinates by reading off its longitude and latitude:

In Three.js, setting texture.mapping = EquirectangularReflectionMapping with SRGBColorSpace enables this as a scene background. In TSL, equirectUV(direction) applies that same conversion, turning a 3D view direction into the 2D UV coordinates for sampling the texture.

Per-fragment fog color from sky. Standard fog blends fragments toward a single constant color. For a scene with a detailed skybox, this looks wrong because the sky color varies by direction. The fix is to compute the camera-to-fragment world direction per pixel (positionWorld.sub(cameraPosition).normalize()) and sample the skybox at that direction for the fog color. Each fragment fades toward the sky color that's actually behind it, producing correct blending from any camera angle. The fog factor uses smoothstep(nearDist, farDist, viewDepth) with positionView.z.negate() for camera-space depth.

Import maps for ES modules. A browser-native mechanism (<script type="importmap">) that maps bare module specifiers (like three/tsl) to actual URLs. When Three.js 0.183.1 restructured its build outputs, three/tsl needed to resolve to three.tsl.js and TSL internally imported three/webgpu as a bare specifier. Both mappings had to be explicit in the import map, or the browser produced "does not provide an export" or "failed to resolve module specifier" errors.

Further reading

For deeper coverage of the technologies used throughout this series, see our companion guides:

• Landscape Generation with Dynamic LOD and Streaming for Browser Open Worlds covers heightmaps, SDFs, marching cubes, Transvoxel, geometry clipmaps, geomorphing, streaming architecture, terrain materials, and vegetation rendering.
• Browser 3D Open World Tech for Multiplayer Creator Worlds covers rendering stacks, WebGPU, physics, networking, multiplayer architecture, and lessons from Skyrim, The Witcher 3, Breath of the Wild, and GTA V.

Thank you for following this twelve-part ride.

Part 1: We started by trying to break it
Part 2: Worker physics and the input lag fear
Part 3: The unflashy spikes that saved us
Part 4: Streaming before fancy terrain
Part 5: Budgeting the pretty stuff
Part 6: Clipmaps changed the plot
Part 7: Marching cubes and the first real caves
Part 8: Integration without losing our baseline
Part 9: Transvoxel started with a scaffold
Part 10: Seam chaos and the corner boss fight
Part 11: Policy mode, not hardcoded mode

Part 12 of 14.
Previous: Part 11 - Policy mode, not hardcoded mode
Next: Part 13 - Terrain sculpting and the death of the math function
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

This page is the navigation hub for the full series.

If you arrived from one random part, start here.

March 2026 update: we added an external implementation cross-check from the Vuntra City devlogs in Part 12 and expanded the companion browser open world tech guide with the same findings.

April 2026 update: Parts 13-14 cover terrain sculpting (Spikes 25-27) and the visual/gameplay layer: multi-material texturing, instanced vegetation, and a character controller with HM+SDF collision (Spikes 28-30).

May 2026 update: the series ran to 29 parts. Parts 15-29 cover the long middle of the build, multiplayer terrain and water, a code-structure refactor, animations and AI scattering, imposters and parallax, the visibility buffer that didn't pay off, clouds and meshlet culling, batched avatars and proximity voice, world persistence and GPU wind, universal characters, three takes on water, a procedural island, grass and occlusion, and a pluggable character controller that drives any body (Spikes 31-60).

June 2026 update: Part 30 adds a collision-aware camera, a spring-arm boom with a pluggable collider contract and a signed-distance probe that stops the view against overhangs and cave ceilings, not just hills.

What "spike" means in this series

A spike is a short, focused experiment.

Each spike tests one risky question. We keep scope tight, measure what matters, and decide what to do next. Think of it as a learning instrument, not a polished feature.

In this project, spikes are mostly standalone pages under /spikes/* that you can run live.

Read the series in order

1. Part 1: We started by trying to break it
2. Part 2: Worker physics and the input lag fear
3. Part 3: The unflashy spikes that saved us
4. Part 4: Streaming before fancy terrain
5. Part 5: Budgeting the pretty stuff
6. Part 6: Clipmaps changed the plot
7. Part 7: Marching cubes and the first real caves
8. Part 8: Integration without losing our baseline
9. Part 9: Transvoxel started with a scaffold
10. Part 10: Seam chaos and the corner boss fight
11. Part 11: Policy mode, not hardcoded mode
12. Part 12: Rings, sky fog, and what we would do again
13. Part 13: Terrain sculpting and the death of the math function
14. Part 14: The world comes alive
15. Part 15: Replace the baseline, then sync it
16. Part 16: Structure for a world that keeps growing
17. Part 17: Animations that didn't need retargeting, and a live asset search
18. Part 18: A scatter brush that feels AI-placed
19. Part 19: The imposter that has to survive a forest
20. Part 20: Faking depth on a flat plane
21. Part 21: A faster renderer that wasn't faster
22. Part 22: Clouds you can light, and culling that has to be fed
23. Part 23: Fifty avatars and a voice in the room
24. Part 24: Saving a world, and wind you can see
25. Part 25: One skeleton, every outfit
26. Part 26: Three ways to make water
27. Part 27: An island from noise, ground that looks like ground
28. Part 28: Grass to the horizon, and ground that hides itself
29. Part 29: One controller, any body
30. Part 30: A camera that respects walls

Live spike map

Start with these if you want to click through the technical timeline directly.

Spike 1 terrain and instancing · source
Spike 2 worker physics · source
Spike 3 Durable Object broadcast load test ran as a service script, not a standalone page
Spike 4 mobile quality constraints, tested via Spike 1 query param
Spike 5 LLM behavior reliability, ran as a script, not a standalone page
Spike 6 chunk load and swap · source
Spike 7 vegetation from density maps · source
Spike 8 terrain material cost · source
Spike 9 cascaded shadows budget · source
Spike 10 clipmaps and geomorphing · source
Spike 11 heightmap chunk streaming · source
Spike 12 WebGPU marching cubes · source
Spike 13 WebGPU integration baseline · source
Spike 14 incremental hardening · source
Spike 15 seam scaffold · source
Spike 16 first Transvoxel face · source
Spike 17 dual MC LOD · source
Spike 18 heightmap seam · source
Spike 19 mixed-resolution corner · source
Spike 20 GPU corner seam · source
Spike 21 GPU MC corner seam · source
Spike 22 MC to HM fallback · source
Spike 23 policy-based chunk modes · source
Spike 24 clipmap rings and sky fog · source
Spike 25 heightmap brush on sampled data · source
Spike 26 SDF brush via GPU compute · source
Spike 27 HM + MC + brush integration · source
Spike 28 multi-material texturing · source
Spike 29 vegetation and shader grass · source
Spike 30 terrain physics and character controller · source
Spike 31 multiplayer terrain sync · source
Spike 32 water and swimming · source
Spike 33 code structure refactor · source
Spike 34 in-world authoring · source
Spike 35 combat animations and retargeting · source
Spike 36 live Poly Haven asset search · source
Spike 37 AI-assisted prop scattering · source
Spike 38 octahedral imposters · source
Spike 39 parallax occlusion mapping · source
Spike 40 visibility buffer renderer · source
Spike 41 imposters in a forest · source
Spike 42 imposter flicker fix · source
Spike 43 atmosphere and volumetric clouds · source
Spike 44 meshlet Hi-Z culling · source
Spike 45 batched avatar skinning and network sync · source
Spike 46 proximity voice chat · source
Spike 47 server-authoritative world persistence · source
Spike 48 avatar rig integration, reused as shared code by later spikes (no standalone page)
Spike 49 GPU wind on props and foliage · source
Spike 50 universal characters and wearables · source
Spike 51 screen-space reflection water · source
Spike 52 planar mirror water · source
Spike 53 production water library · source
Spike 54 procedural island generation · source
Spike 55 terrain shading and tiling breakup · source
Spike 56 GPU cross-quad grass · source
Spike 57 terrain occlusion culling · source
Spike 58 pluggable character controller · source
Spike 59 controller with a real avatar · source
Spike 60 Synty polygon animations · source

By Mariana Muntean, CEO of Cinevva

We made a game where your snake is the paddle and the bricks fight back. It shipped on web, mobile, and PC. It took two of us about three days. On and off, not crunching. And it's genuinely fun to play.

That last part is the thing worth paying attention to.

The mashup nobody asked for

Snake is about growth and spatial awareness. Arkanoid is about reflexes and angle prediction. They come from completely different design philosophies, and mashing them together sounds like the kind of pitch that gets politely declined.

But A Breaker Belt makes it work. You're a cosmic serpent, a living arc of neon current stitched from drift-metal vertebrae and comet silk, threading through an asteroid field of breakable blocks. Your head is the paddle. Your growing tail is both your greatest weapon and your most constant threat. The orbs ricochet off your body to shatter bricks, but one wrong turn into your own tail and you're done.

It's the kind of weird cross-genre experiment that usually dies before anyone gets to play it, because the development cost of finding out whether a weird idea works has traditionally been measured in months. Here it was measured in afternoons.

What actually shipped

The scope is what makes this interesting. This isn't a game jam prototype with placeholder rectangles and no sound.

The game runs 50 waves deep. That's not 50 variations of the same brick wall. The formations evolve from gentle onboarding arcs into fortress rings that demand angled shots through side gaps, then into layered diagonal mazes with one-tile-wide openings that require precision steering. Explosive bricks blow their neighbors apart. Phantom bricks flicker in and out of existence. Regenerating bricks heal back after you break them, forcing you to prioritize targets instead of sweeping left to right. Portal bricks teleport your orbs across the arena. Gravity wells bend your shots into slow, curving hymns. Laser emitters sketch red lines across the void. Mimic bricks look harmless until they decide they're not. By wave 15, you're navigating something that feels less like a puzzle and more like a living system that's learning your habits.

The music isn't a loop. It's a reactive soundtrack that builds with your gameplay. The underlying system runs a bass line, lead synth, pad, kick, snare, and hi-hat in E minor at 140 BPM, and as the action intensifies, additional percussion and synth layers fade in. When things calm down between waves, ambient pads take over. The music breathes with you. A dedicated composer would spend weeks tuning that kind of responsiveness. Here it was part of the creative flow.

The sound effects aren't samples pulled from a free pack. Every brick shatter, power-up pickup, orb bounce, and collision is synthesized in real time. Different pitch for head contacts versus tail contacts. Warm reverb for the spacey feel. Lowpass filtering to keep things satisfying without getting harsh. When you chain a combo, the audio tells you before the screen does.

And then there's the storytelling. Each wave opens with a narrative beat delivered by AI-generated voice. The writing has genuine personality. Wave one: "They call it the Breaker Belt: a ribbon of engineered debris that circles the old star like a warning." By wave 38: "The Belt stops feeling like a wall and starts feeling like a mind. It tests not your reflexes, but your habits. You break the habit. The Belt notices." It's 50 chapters of cosmic mythology that makes you care about why you're a snake breaking bricks in space.

The backgrounds evolve too. Early waves are calm indigo starfields with soft meteor rain. By mid-game, aurora bands and nebula clouds appear. Late game goes full Ion Storm with sharp cyan streaks against near-black space. Wave 15 and beyond, you're in Event Horizon territory: deep void punctuated by slow-moving nebula filaments and faint black hole lensing. The game communicates progression through atmosphere as much as difficulty.

All of this runs on keyboard, gamepad, or touchscreen. Published to web, mobile, and PC from one codebase. No separate builds. No porting.

The team that wasn't needed

Here's the part that should make any game developer pause.

A game with this depth of content would typically need a game designer, a couple of programmers, a 2D artist, a sound designer, a music composer, a level designer, a narrative writer, and QA. That's eight or nine people. At a modest indie pace, you're looking at three to six months of coordinated work. Standups, Jira tickets, asset pipelines, platform-specific debugging.

Two of us made this in a long weekend on the Cinevva Engine.

The talent required didn't change. The ratio between creative intent and implementation overhead did. The time was spent deciding what the game should feel like, not fighting tools to make it happen.

Why this matters if you make things

The interesting question isn't whether AI tools can help make games faster. That's been answered. The interesting question is what happens to ideas that used to be too risky to try.

"Snake but you're the paddle in an Arkanoid arena" is not something a producer greenlights. A few indie devs have tried variations of this mashup on itch.io (BreakSnake, SnakeOut, Snake Break), but they're all small game jam experiments. The genre fusion has never been given a real production pass with reactive music, AI narration, dozens of brick types, and 50 waves of escalating level design. In traditional development, that kind of polish on a risky concept gets killed in a meeting before anyone writes a line of code.

When trying something weird costs an afternoon instead of a quarter's budget, the strange ideas get built. Some of them turn out to be genuinely good. A Breaker Belt is one of those.

Play it. Or make your own.

A Breaker Belt is playable right now on web, mobile, and PC. If it makes you want to build something, the Cinevva Engine is free to use. Describe what you want, iterate on what comes back, ship when it's ready. The music, sound effects, art, and 3D models are all built in.

Your weird game idea might be three days away from existing.

Play A Breaker Belt | Build your own game | Browse community games

Related:

• Vibe coding is the new game jam — how AI tools collapse the gap between idea and prototype
• Game Jams & Hackathons — the jam format that makes weird mashups possible
• Web Game Engines Comparison — engines for shipping to web, mobile, and PC

By Mariana Muntean, CEO of Cinevva

We have a music generator on the Cinevva platform so game creators can make game soundtracks and SFX without licensing headaches. What happened next, we did not plan for. People started making music because they wanted to make music. Not for games or projects. Just music production.

Bella Bay made over 100 tracks in two weeks

I'm not exaggerating. One of our creators, Bella Bay, generated over 100 tracks in about two weeks. When you listen through them on Cinevva Radio, you can hear the progression. The early tracks are experiments. The later ones sound like someone who found their style. That kind of creative acceleration doesn't happen when you're fighting your tools. It happens when the tools get out of the way.

Bella Bay isn't an outlier in spirit, just in volume. All across the platform, people started treating the music generator not as a utility for game assets but as a creative instrument. Producers experimenting with genres they'd never tried. People iterating on a sound until it clicked. Bedroom artists who'd never had access to a full production toolkit suddenly had one and went all in.

So we built a radio

It had to be done.

We had all these tracks sitting in people's accounts with no collective space. No way to discover what others were making. No way to stumble onto a track that changes your afternoon.

Cinevva Radio is now live. Eight stations. 362 community-created tracks and growing every day. Every single song was made by someone on the platform. You open it and something is playing. You don't have to search. You don't have to decide. You just listen.

Soundstage is our biggest station. 111 tracks of cinematic and epic scores. I honestly didn't see that coming. People love making dramatic, film-style music.

Discovery caught everything that doesn't fit neatly into a genre. 78 tracks. Latin beats next to Afrobeats next to country next to something that defies description. This station is wild.

Main Stage is pop and vocal tracks. 56 tracks with full lyrics and vocals. People are writing love songs, breakup songs, worship music, ballads. Some of it is genuinely catchy.

Voltage is rock and metal. 53 tracks. Guitar riffs, punk energy, grunge, hard rock. I keep this one on while working.

Lo-Fi Cafe is exactly what it sounds like. 25 chill ambient tracks for studying, working, or just vibing.

Electric Dreams has 22 electronic and synth tracks. Synthwave, techno, EDM, drum and bass.

Ivory Tower is classical and orchestral. 10 tracks. Piano pieces, string arrangements, symphonic stuff. Small but growing.

The Cipher is hip-hop and rap. 7 tracks so far. Newest station, still finding its voice.

What you see when you listen

When you open Cinevva Radio, it's a live stream. Think of it less like a playlist app and more like an actual radio station. Tracks play continuously. You can react in real time, chat with other listeners, and see who made each track.

Creators get credited on screen while their track plays. Their name, their prompt, the genre. If you hear something you like, you know who made it. It's community-created content with a discovery layer on top. No algorithms deciding what's worthy. No gatekeepers. You made a track, it goes on the station that matches its genre, and people hear it.

This is bigger than a feature

For decades, music production required expensive software, years of training, and access to equipment most people couldn't afford. What we're seeing is a different kind of creator. People who think in descriptions and feelings rather than notes and time signatures.

"Rainy night jazz with a broken piano" is a creative direction. The person who wrote that prompt made an artistic choice. They directed the mood, the instrumentation, the emotional register. They just don't happen to play piano.

I don't think that makes their output less valid. I think it means the definition of "musician" is stretching. And watching someone like Bella Bay go from zero to a hundred tracks in two weeks tells me the creative drive was always there. The tools just weren't.

What's next

We're working on community profiles where producers can showcase their catalog and build a following. The charts page already shows community creations across all tools, and we want to bring that same energy specifically to music.

But right now, the radio is live. Go listen. And if you want to make your own tracks, the music generator is free to use. Your track might end up on the air.

Listen to Cinevva Radio | Make music | Browse community creations

Related:

• Frontier Open-Source Gen AI Models — the AI music and audio models behind the scenes
• Web Audio API for games — building interactive audio in the browser
• Vibe coding is the new game jam — how describing intent becomes the primary creative input

By Mariana Muntean, CEO of Cinevva

AI has essentially commoditized raw logic and computational ability. The skills we used to worship, the mental math, the pattern recognition, the ability to grind through complex algorithms, AI does all of that now. Faster. Better. Without getting tired. Do we still need to know it? Absolutely, but perceptions change. Now everyone needs to adjust to the new era - an era of intuitive intreaction and outcomes.

According to Jensen Huang, NVIDIA's CEO, what matters now is the ability to sense a "vibe" and see around corners before the data appears. The intersection of technical literacy and deep empathy. The intuitive understanding that silicon can't touch.

I've never heard anyone with his credibility say something that validated my entire life trajectory quite so directly.

The SAT and the system that wasn't built for me

A few years back I took the SAT and failed. I'm not proud of it, but I also didn't try again. Something felt fundamentally wrong about the whole thing, and I couldn't shake that feeling no matter how much people told me to just study harder and take it again.

Looking back, I think I was right.

The SAT is designed for the American education system. That sounds obvious, but the implications run deep. American high schools teach to specific patterns, question types, and ways of framing problems. Students grow up marinating in that style of standardized testing from elementary school onward. By the time they hit the SAT, they've internalized the rhythm.

International students don't have that advantage. We come from systems with different educational philosophies. European schools often emphasize depth over breadth, essay-based examination over multiple choice, oral defense over bubble sheets. Asian systems have their own standardized tests, but they measure different things in different ways. South American, African, Middle Eastern educational traditions each carry their own logic.

When you drop an international student into the SAT, you're not just testing their knowledge. You're testing how quickly they can adapt to a foreign testing culture while simultaneously demonstrating mastery of content. You're testing cultural fluency as much as academic ability.

I was expected to prep for this over a summer and ace it. Learn an entire testing culture, unlearn my own educational instincts, and perform at a level that would impress American admissions officers. All in a few months.

I chose not to.

When you're young, you're smart in different ways. Intuitive ways. I was clearing a path for myself, even if I couldn't articulate exactly why at the time. Something in me knew this system wasn't mine.

Following the creative thread instead

I studied game development and design because I loved the idea of using creativity and visual effects to build virtual worlds people could play and interact with. I loved the intersection of art and technology, storytelling and interactivity.

What I found shocked me.

Games require serious technical depth. Physics simulations, collision detection, vector math, lighting calculations, optimization. I knew that going in. The math and engineering aren't obstacles to game development. They're part of what makes games work.

The problem was the gap between creative vision and implementation. The engines and tools dominating the industry were designed by engineers for engineers. Everything ran on "ifs" and "thens" and node-based blueprints. You wanted a vortex effect? Learn shader programming. Specific lighting mood? Dig into material graphs. Character movement that feels right? Debug character controller or physics parameters for hours.

If you're a visual person, if you think in vivid colors and moving images, if ideas come to you as fully formed scenes with sound and texture and emotional weight, you had to translate all of that into technical language before you could build any of it. You see a world in your mind, complete with lighting and atmosphere and the way characters move through space. Then you sit down at your computer and spend the next six hours debugging why your character falls through the floor.

The technical foundation matters. But the tools forced creators to live in implementation details instead of abstracting that complexity away. Game creation should feel like telling a story or directing a movie where people get to participate. That's the magic of the medium. Instead it felt like taking an engineering exam before you could even start.

Movie directors don't spend years learning physics engines before they can express their vision. They get a budget and a team that handles the technical execution. But in indie game development, you rarely have a budget. What you have is time and access to tools. And if you're a technical person, you can build a killer game. But only if.

This is how we got titles like Limbo, made by a small team with a singular artistic vision and the technical chops to execute it. Or Undertale, created largely by one person who happened to have the right combination of creative instinct and programming ability. Or Stardew Valley, where Eric Barone spent years teaching himself everything from pixel art to music composition to C# programming.

These games succeeded against enormous odds. But for every Limbo there are millions of creative visions that died because the tools demanded technical fluency their creators couldn't provide. Less than 3% of indie game developers ever achieve meaningful success. How many brilliant games never got made because their creators hit a wall of "ifs" and "thens" and gave up?

The barrier to entry wasn't creativity. It was technical gatekeeping built into the tools themselves.

Building what should have existed

So 5 years ago I started building something different.

The pitch was simple: game development should be accessible to anyone with a creative vision. You shouldn't need a computer science degree to express yourself through interactive media. The tools should adapt to how creative people actually think, not the other way around.

VCs from Sequoia, Pear, Draper, and dozens of other firms told me it wouldn't work. It's B2C. The market isn't there. Indies don't pay for anything. You can't simplify game development without sacrificing capability. Gamers want complex games, and complex games require complex tools. Millions of excuses dressed up as market analysis.

People told me I was crazy. Maybe I was. But I kept coming back to the same question: why should multimillion dollar budgets be a prerequisite for creative expression? Movie directors and celebrity game producers have teams and resources. Everyone else gets a code editor and a prayer. I wanted to build the thing that closes that gap. You describe what you want, and it happens in front of your eyes. Every part of me knew this was right. I could feel it in every cell of my body.

Today thousands of people use Cinevva daily for 3D game assets, games, music, levels and experiences. Millions of views on projects created so far. Growing every single day. A two-minute pitch to Sand Hill Road isn't exactly the format for "I failed the SAT but trust my intuition."

What intuition actually means

Huang wasn't just making a philosophical point. He was describing a real shift in what constitutes valuable intelligence.

For decades, we optimized for the wrong things. We built educational systems that rewarded memorization and calculation. We designed standardized tests that measured pattern-matching against previously seen problems. We hired people based on credentials that proved they could survive four years of academic gatekeeping. AI just made all of that less special.

What AI can't do, at least not yet, is sense what's missing. Feel when something is off. Intuit what people need before they can articulate it themselves. Read a room. Understand context that isn't captured in any dataset.

I poured my time, international life experience, money, and intuitive knowledge into building Cinevva. That's a mix hard to obtain in college. Hard to test for on the SAT. Hard to capture in any credential system designed before AI made raw cognitive horsepower abundant.

Sixteen or twenty years ago, computer scientists decided what tools should look like and how they should work. They built for themselves, for people who thought like them. The rest of us were expected to adapt. That era is ending. The people who will shape what comes next are the ones who understand what humans actually want. Who can feel when something is wrong and when something is right. Who build for people instead of for technical elegance.

I trusted something in myself that the system told me was worthless. And I was right.

Related:

• The job market is transforming — from credentials to skills
• Online Game Development Courses — skills-first paths that bypass traditional gatekeeping
• Everyone wants to be the AI game engine now — the industry shift toward tools that adapt to how people think

By Oleg Sidorkin, CTO of Cinevva

AI in games turned into a genuine minefield somewhere around mid-2024. Jobs disappearing. People convinced they're next. Copyright questions that not even the lawyers can untangle. Endless aesthetic debates that loop back on themselves. Steam drowning in stuff nobody asked for. And underneath everything, this nagging worry every creator has now: "am I actually making something here, or just... typing prompts?"

We run a platform. You learn one thing fast doing that.

Nobody likes feeling tricked.

These numbers surprised us

We figured AI adoption would grow. Not like this though. Here's where things landed by late 2025:

Sources: Tom's Hardware / Totally Human Media analysis, GDC 2025 Developer Survey, Unity 2025 Gaming Report

What actually happened to make players this skeptical

This didn't come from nowhere. Real things went wrong. And people remember.

Voice actors found out they'd been cloned — on launch day

Tomb Raider 4-6 Remastered shipped with AI-generated versions of the original voice performances. The actors learned about it the same moment everyone else did. Launch day. The publisher eventually patched the voices out after legal pressure built up. That eleven-month SAG-AFTRA strike? This exact scenario was driving it.

"AI slop" became a thing people say now

Call of Duty: Black Ops 6 quietly added AI disclosure to its Steam page. After it was already out. Players had noticed the weirdness — visual glitches scattered everywhere. One loading screen character had six fingers. "AI slop" turned into shorthand for anything that looks... off. Hollow. Like nobody cared enough to check.

An award nomination vanished

Clair Obscur: Expedition 33 got its Game of the Year nomination pulled at the Indie Game Awards. The shipped game didn't use AI though. The problem was AI placeholders during development — internal stuff that never made it to players. Final assets were entirely human-made. Didn't matter. Weeks of arguing about where exactly the line should be.

Teams that never touched AI had to prove it

Chessplus and Peak both got hit with AI accusations. Neither used any. Both were award nominees. Both development teams ended up digging through old screenshots and layer files just to demonstrate their work was handmade. The Peak team put it best: "We might be slop, but we're human-made, locally-sourced artisanal slop."

Studios went in completely opposite directions

SNK — Discord moderators walked out after AI-looking visuals showed up in a Fatal Fury: City of the Wolves trailer. Games Workshop — banned AI entirely across all Warhammer properties. Larian Studios — said they used AI only for very early concept sketches on Baldur's Gate 3, nothing in the final game. Tim Sweeney — declared Steam's AI labels worthless and said to scrap them. Valve — shot back that devs complaining about AI labels usually worry their work looks "low effort."

Finding games turned into a trust problem

Stuff gets made faster than anyone can properly evaluate it now. The questions changed:

What am I even looking at here? Who made this? Am I going to regret the time I spend on it? Does any of this match what the trailer promised?

There's probably no grand resolution coming. No definitive ruling on AI versus human-made.

What's more likely: filters, real transparency, and incentive structures that push toward honesty.

Small studios stuck in the middle of all this

Indie developers landed in a strange spot.

The upside is genuinely hard to dismiss: You iterate faster. Costs drop when four people are making everything. Solo devs can actually finish things now. Localization stops eating your entire budget.

The downside is just as real: Output that feels generic. Training data and IP concerns that lawyers won't touch yet. Shipping systems you don't fully understand — some people call it comprehension debt. Getting grouped in with the flood of low-effort releases. Nearly half of surveyed developers think AI makes games worse overall.

Unity's 2025 report says 79% of developers feel positive about AI tools. Sounds pretty definitive. The reality is messier. Teams doing this well tend to use AI for the boring parts — grunt work, rough passes, QA tedium. Creative direction? That stays human.

Where Cinevva lands: neutral on AI, strict on honesty

We don't turn games away for using AI. We don't give them special treatment either.

The rule is simple: if AI was involved, say so. Players decide what they care about. Filters actually work then.

• AI-generated content policy

Filters work better than arguments

The AI debate in games isn't reaching consensus anytime soon. Probably never will. But individual preferences? Those are clear enough.

Some players specifically want human-directed art. Writing that came from a person. Visible craft.

Others genuinely don't care. Fun is fun.

Filters let both groups find what they're looking for. Nobody has to win.

Payment models matter more than anyone's opinion

When revenue ties to playtime instead of unit sales, you make money by:

Getting players hooked fast. Keeping their attention. Delivering what your marketing said you would.

Quality becomes the obvious path. How you made it matters less.

Overpromise in your trailer? Players leave immediately. Retention tanks. Show them exactly what they're getting? They stick around. Playtime builds. Revenue comes. The economics sort themselves out.

What 2026 probably brings

More rules — EU AI Act keeps expanding. US protections for voice and likeness growing, especially after SAG-AFTRA.

Specialized tools — AI built specifically for small teams. Designed to keep humans steering.

Smarter labels — "Made with AI" is too crude. Expect distinctions between AI-assisted workflows and AI-generated final assets.

Audiences splitting — Some players will deliberately seek out traditionally-made games. Others won't give it a thought. Both groups are large enough to build for.

Platform competition — How storefronts handle transparency and discovery becomes a real differentiator.

What actually moves things forward

Arguing won't settle the AI question. What does:

1. Players picking based on what genuinely matters to them
2. Creators being honest about how they work
3. Platforms building tools that help both groups find each other

That's the post-AI economy. Not warring camps. Trust holding the whole thing together.

Related:

• AI-generated content policy
• For game creators
• FAQ
• Frontier Open-Source Gen AI Models — the specific models and how they work
• Open source has an AI pollution problem — what happens when AI output floods open-source projects

By Oleg Sidorkin, CTO of Cinevva

I watched my cousin graduate with honors in 2023. Computer science degree from a good state school. Solid GPA. He spent fourteen months applying to jobs before landing one. Meanwhile, a friend who dropped out sophomore year to build indie games had three offers within a month of deciding to look.

That's not an anomaly anymore. That's the pattern.

The numbers finally caught up to what we've been feeling

By 2025, 90% of HR leaders reported hiring outside traditional four-year degrees (Fortune). A quarter of U.S. companies dropped bachelor's requirements entirely (HR Dive). And here's the part that stings if you just finished paying off loans: 94% of employers say skills-based hires outperform those hired on credentials (Forbes).

Verizon now says 99% of their roles don't require a degree. Sergey Brin admitted Google hires "tons" of people without bachelor's degrees. IBM made half their U.S. openings degree-optional through their "New Collar" program.

This isn't companies being charitable. They figured out that degrees weren't predicting who'd actually be good at the job.

Why the old system broke

The honest answer? Degrees became a lazy filter.

When you're hiring and you've got 400 applications, requiring a bachelor's degree cuts the pile in half. It doesn't tell you who can actually do the work. It tells you who had the money, the time, and the family stability to sit in classrooms for four years. That correlation with ability was always weaker than we pretended.

And now three things happened at once:

The skills moved too fast. Game engines, AI tools, web frameworks. By the time a curriculum committee approves a course on something, that thing is already outdated. A four-year degree teaches you theory from four years ago. In tech, that's ancient history.

Portfolios became undeniable. Why guess whether someone can code when you can look at their GitHub? Why wonder if they can ship a game when their itch.io page has five finished projects with player reviews?

Companies got desperate. The talent shortage is real. Excluding everyone without a degree means excluding people who might be exactly what you need. Some hiring managers figured this out the hard way, after watching self-taught developers run circles around their credentialed hires.

The game industry saw this coming

I think games have been ahead of the curve here, and it's worth understanding why.

Studios never really cared where you went to school. They cared what you shipped. A polished 48-hour jam game tells a hiring manager more than a four-year game design degree ever could. It proves you can finish things under pressure. It proves you made hard decisions about scope. It proves the game is playable, not just theoretical.

If you're trying to break into games in 2026, here's what actually matters (Dice, CombineGR): two or three polished, playable demos. Case studies explaining what you did and why. Evidence that you finish things. Fluency with at least one major engine, shown through real projects.

Hiring managers aren't looking for potential. They're looking for proof.

The uncomfortable part nobody talks about

Here's something that frustrated me when I dug into the research.

A Harvard/Burning Glass study found that companies dropping degree requirements often didn't actually hire more non-degreed candidates. The increase was only about 3.5 percentage points (Forbes). The policy changed. The hiring practices lagged.

That means if you're going the non-traditional route, you still have to work harder. The door is more open than it used to be, but you're not walking through on equal footing yet. Your portfolio needs to be undeniable. Your projects need to speak louder than someone else's credential.

It's not fair. But knowing it helps you prepare.

What I'd tell someone starting out right now

If you're in school, don't stop. But understand that the degree alone isn't enough anymore. Build things on the side. Do game jams. Get a Google Career Certificate or Unity certification. Treat the degree as one credential among several, not the credential.

If you're not pursuing a degree, you have a different path but not necessarily a harder one. Build aggressively. Ship things. Document everything. Your GitHub, your itch.io page, your personal site. That's your credential now.

Either way, practice explaining your work. Not just what you built, but why you made the choices you made. What you'd do differently. What you learned. Interviewers remember people who can articulate their thinking.

This is bigger than hiring

What's happening here isn't just a shift in how companies fill roles. It's a shift in what we collectively value.

For decades, credentials served as a filter. Expensive, time-consuming, but legible. If someone had a degree, you could assume certain things. It was a signal, not a direct measure, but it was good enough.

That signal is breaking now. Technology makes it possible to see what someone can actually do. Remote work proved that outputs matter more than where you sat. AI is making theoretical knowledge less valuable than practical application.

I find this genuinely hopeful, even if the transition is messy. The question used to be "where did you study?" Now it's "what can you build?"

That's a better question.

Sources

• Fortune: 90% of HR leaders hiring outside traditional degrees
• Forbes: 90% of companies make better hires based on skills
• Forbes: Companies dropping degree requirements but hiring few non-degreed workers
• HR Dive: Employers eliminating degree requirements
• Computerworld: Tech firms move away from college requirement
• Dice: Aspiring video game designers in 2025
• CombineGR: 2025 Global Gaming Employment Outlook

Related:

• How to succeed in game jams
• Online Game Development Courses — skills-first learning paths for every budget
• Agentic AI code tools — the tools reshaping what skills matter
• The intuitive mind — why intuition matters more than credentials