Light that costs the world, not the screen

I was testing a small turn-based game in a phone browser. It looked fine on a desktop, but a phone quietly turned a 360 by 800 page into a 1080 by 2400 drawing buffer. The old light grid grew with that buffer. Every extra display pixel asked for more lighting work, even though the room and its lamps had not changed.

There were simpler browser problems first. The web loop drew without waiting for the browser's next animation frame. The canvas buffer did not match its visible size, and the page missed the mobile viewport setting. I fixed those before changing the lighting, then added a pixel-ratio cap and frame-rate cap for lower quality levels. Otherwise I would have been measuring the wrong problem.

Put the grid on the map

The earlier lighting post explains the radiance cascades: nearby probes look in a few directions, and distant probes look in more. Until now, their grid size followed the screen. I changed it so one light texel covers a fixed distance in the game world. The screen can get denser without forcing the whole light simulation to grow with it.

This is still a window around the camera, not a light map for the entire world. The window moves in world-sized steps. It includes a reach beyond the visible area, where an off-screen lantern or a wall can still affect the edge of the view. The visible scene keeps its full-resolution colors and surface directions. The light calculation uses a coarser world grid, with a finer region for the near cascades over the camera view.

Think of drawing a map under a movable frame. The streets on the map do not shift when you nudge the frame. The frame only moves to the next grid line when it needs more map. That stopped light from changing every time the camera moved by a few pixels. It also meant a lamp just outside the frame could light what I could see inside it.

The expensive distance fields now stay in place while their inputs stay the same. They describe where light emitters and blockers are, so changing a lamp's color does not require new fields. When a door opens or a chunk loads, Quaso updates the changed area plus the field's 32-texel reach. When the camera moves, it shifts the old field content into the new window. In a 60-second camera-pan test, the world grid rebuilt once at startup. The old screen grid rebuilt during 26 of the 31 measured seconds.

Far cascades also take turns. A nearby fire flicker updates every frame, while distant light changes less often. Quaso gives phones Low or Medium settings with fewer lighting pixels and bloom levels. A short startup watcher uses the median frame time over two-second windows to step down if the device is too slow. One hitch does not decide the quality level.

What the measurements say

On the test map at 1080 by 2400, cached lighting work fell from 27.5 million full-screen fragment pixels per frame with the old High grid to 10.7 million with the world grid, fine near view and staggered far updates. That is a count of shader work in headless software rendering, not a phone frame-time measurement. My phone test felt fast and touch input worked, but I did not record hardware timings.

The new boundaries exposed bugs. Rays that left the light window picked up clear sky, which made a bright band near one side of the view. Now sky and sun are sampled at a fixed reach. This also means a room wider than twice that reach can get some sky in its middle. Small lamps disappeared from coarse image levels until I aligned the intermediate texture sizes and fixed a skip step in the ray march.

Small lamps can still look dimmer when they cover less than two light texels. Their brightness can also depend a little on where a coarse probe lands. A tile-based game can anchor the grid to its tiles, but the underlying artifact remains. The light is cheaper and steadier now, with a few edges left to sand down.

Quaso still draws the same flat 2D light. This work changed where it spends its time.