Road to 1.0: Full Speed From the First Frame

Ready When You Are

Washoi alpha 7 is out. Alpha 6 removed work the renderer was doing twice. Alpha 7 looks at the moments when that work hurt most: the first seconds of a match, the frames after a map change, and the view while something is exploding next to you.

On WebGPU, a map no longer stutters for its first seconds while the browser compiles shaders. Maps with water no longer open at a low frame rate. A world that could stop drawing after a few map changes now keeps drawing. And the camera shakes less when plasma and explosions are flying.

Underneath, the map draws in fewer calls, and the CPU stops rebuilding skeletons, sprites and mesh lists that have not changed.

On the Babylon.js Showcase

Some news first: Washoi is now listed on the Games made with Babylon.js showcase at babylonjs.com. SHAG Engine is built on Babylon.js, and much of this release is work inside the parts of Babylon that a fast arena shooter pushes hardest.

A Calmer View Under Fire

Camera shake tells you that something hit you or went off nearby. It should not make sustained fire hard to watch.

Plasmagun hits and nearby plasma impacts now shake the camera half as much. Rocket and grenade explosions shake it only within 324 units instead of 540, so the shake stays closer to the blast. Voltaic hits shake it 30% less.

No Stutter at the Start

On WebGPU, each material's render pipeline used to be built the first time it came into view. The browser then compiled it before the frame could finish. On washoi_dm5 that meant about 105 pipelines in the first seconds of play, frames of up to 2.4 seconds and 5–7 fps for two seconds. It was the worst possible time to lose the frame rate.

The loading screen now draws the whole map once and waits for the GPU. That adds 0.8–2.8 seconds to loading on the tested maps, and play opens at 62–74 fps instead. A slightly longer loading screen is a better trade than a frozen first fight.

Babylon was also giving every material a second pipeline once a player outline had been drawn over a transparent surface. A stencil mask that nothing reads stayed in the pipeline key. That mask is now reset when stencil is off. WebGL2 is unchanged.

Water Without the Slow Start

A map with water had its own slow opening. The loading screen tried each pool's reflection capture once. If that capture's shaders were still compiling, it gave up, and play retried the capture every frame, compiling one more map material each time.

On washoi_dm11 FFA with four bots, the first seconds ran at 11–77 fps. Loading now keeps the capture and waits up to three seconds for its shaders. Play opens at 130–165 fps on WebGPU and WebGL2.

A World That Keeps Drawing

There was a nastier WebGPU problem after several map changes. The world could stop drawing, with every frame rejected as "buffer binding is too small", or a draw could fail on a missing light texture.

Frozen world surfaces were re-checked when their lights changed, but not when only the order of those lights changed. Babylon re-sorts every surface's lights whenever any light is added, including one belonging to a model. A surface could then bind one light's data where its shader expected another's.

The check now follows each world surface's lights in order. The dm5 → dm2 → amphi1 → dm11 sequence that failed now runs without errors.

Fewer Draws for the Map

Plain map surfaces that differ only in their images now share a draw. Their base, normal and gloss images become layers of texture arrays, and each surface picks its own layer. On washoi_dm5, about 55 surfaces draw as 17–18 meshes, so 93 opaque map draws a frame become 63–70. On washoi_dm2, 49 surfaces draw as 11, and 66 draws become 37.

Map sprites (halos, coronas and flares) now turn toward the camera in the vertex shader instead of on the CPU. Their geometry used to be rewritten and uploaded every frame the camera moved, at about 0.18 ms a frame on washoi_dm5; that is now about 0.01 ms. Reflections and sky portals also turn each sprite toward their own camera, rather than the main camera.

Additive sprites that share a texture now draw as one mesh with one vertex upload a frame. washoi_dm2's 62 sprites draw from 4 meshes, and washoi_dm5's 76 from 42. Alpha-blended sprites, whose look depends on draw order, keep a mesh each.

WebGPU now submits frames through render bundles by default, rather than only with ?ncm=1. When the CPU is the limit, throttled tests on washoi_dm5 ran 9–14% faster with matching pictures. ?ncm=0 turns it off for a session.

The shared draws and batched sprites were checked for matching frames on WebGL2 and WebGPU. The numbers come from those maps and tests, rather than a promise about every player's frame rate.

Stop Rebuilding What Did Not Change

Most of the remaining work in this release is the CPU doing less.

A ragdoll now copies its physics pose onto the skeleton in one pass. Babylon's ragdoll had rebuilt the whole 65-bone rig once for each of its 15 physics bodies, every frame. On washoi_dm5 that copy fell from about 35–57 µs to 5–9 µs per ragdoll per frame, with identical frames and unchanged physics. A model with mirrored or uneven scale keeps Babylon's own copy.

Animated models no longer rebuild their skin matrices on frames where their pose did not change. A player clip stepping at 30 Hz, or a weapon holding still, used to rebuild and re-upload its matrices every frame anyway. In the washoi_dm5 demo, those rebuilds fell from about 3.7 to 0.75 a frame, and skin preparation halved on WebGL2.

The first-person weapon camera no longer evaluates every mesh in the scene to draw the handful of weapon meshes it can see. The filter that prevents this was only on by default in Firefox; it is now on in every browser and on WebGPU. On washoi_dm5, the weapon camera's mesh selection fell from about 1.0 ms to 0.15 ms a frame on WebGL2.

Soft halos and flares no longer search every mesh on each camera pass to find themselves; each soft material keeps its own list. Hidden pickup models stop evaluating constant animation clips every frame, while animated sources and held-weapon animations keep playing.

A Lighter Vanguard, an Honest HUD

The Vanguard player model's package is about 69% smaller: 1.20 MB instead of 3.81 MB, reducing player-model downloads on EU and US.

The HUD's ammo and armor bars now animate without recalculating their layout on each animation frame. Switching between weapons with the same ammo count now updates the fill for the new weapon's capacity. The air meter also reliably shows its warning and DROWNING label, even when its displayed fill stays at the same step.