Status
SteamPeaks
ChartsSalesUpcomingPatchesNewsCalculator
New on SteamEvery app, DLC and depot the minute Steam creates itAppsEvery app on Steam, newest change firstPackagesSubs and bundles, and what each containsDepotsDepots, manifests and install sizesTagsSteam's user tags and the games under themDevelopers & publishersCompanies and their cataloguesTechnologiesEngines, SDKs and anti-cheat found in the filesChange historyEvery PICS changelist as it lands
SignalsNineteen readings of the whole catalogueCompareAny games side by sideRecordsAll-time peaks and the days they were setReportsWeekly and monthly write-upsAlerts & newsroomWatch a game, get told when it movesSteam statusIs Steam up, right nowWeb API explorerTry the endpoints in the browser
NewsSteam's own announcements and the sales calendarCalculatorWhat a Steam account is worth, and its pile of shame
/
Sign in
/
SteamPeaks
The ultimate resource for Steam data.
ExploreChartsSalesSales and festsUpcomingPatchesNewsRecordsTrendingSignals
DatabaseAppsPackagesDepotsTagsDevelopersTechnologiesChange history
ToolsCalculatorCompareSearchAlertsSteam statusAPI
SiteMethodologyFAQDiscordSupportSign in via Steam
Not affiliated with Valve or Steam. Game names and artwork belong to their owners. All times UTC.
PrivacyCookiesFair useStatus
CarveLightNewsHow the lighting works
Community

How the lighting works

CarveLight · published 10 Aug 2026, 10:28 UTC

All newsPlayers around this dateRead on Steam

Hi.

The game is called CarveLight because carving the terrain and lighting it are the same system. This post is about the lighting half.

Everything is dynamic

Every light in the game is fully dynamic. Nothing is baked, there are no shadow maps, and no part of the lighting survives from one frame to the next. Every shadow in every frame is computed from scratch.

This was a hard requirement for the lighting system as there are no static bodies in the game. Cars, terrain, weapons... everything can move freely. 2D games tend to use shadow volumes for lights, but since CarveLight uses precise vector graphics I though a more precise solution is needed.

Ray casting

For each pixel, for each light, the shader traces a ray to the light. If it gets through, the pixel gets light with a distance falloff and a cone term. If it's blocked, it gets nothing. The occluders are all edges and circles in the scene. Carve a hole in a wall and light comes through the hole on the same frame the hole exists (see screenshots below). There's no special case for it — a ray either fits through the gap or it doesn't. The same goes for anything that moves. Headlights swing with the car, thruster cones sweep across the ground as you fly, and a grenade lights up the whole room it's sitting in while it ticks. Fire and sparks are left out of the occluder list on purpose. They glow, they shouldn't cast shadows.

Wall intact

Same camera, wall carved out

Making it fast

To keep the rays cheap, the game rebuilds a BVH every frame — a tree of boxes over all that geometry, so a ray can discard most of the world in a few tests. Perimeter-based SAH build, 16 bytes per node, traversed on the GPU with no stack: each node stores where to jump when the ray misses it. Shadow edges are a hard yes/no, so they alias. The fix is 8 samples per pixel per light, which is wasted everywhere except on pixels actually sitting on a light/shadow boundary. So the shader takes one sample, checks what the neighbouring threads got, and skips the other 7 if the whole group agrees. Only boundary pixels pay full price. This is a very cheap test on modern GPUs using wave intrinsics.

Shadows come out hard-edged. The lights are points with no area, so there's no penumbra — which suits the look, and keeps it to one ray per sample.

Cheers!