schmelczer-dev/src/content/posts/sdf-2d-ray-tracing.md

title	description	date	projectPeriod	thumbnail	tags	featuredOrder	role	stack	scale	outcome	audience	links	media
A 2D Ray Tracer for the Browser, Tuned for the Phone in Your Pocket	My BSc thesis library. The mobile GPU constraint shaped the architecture: tile-based passes, deferred shading, shaders generated per scene and device.	2026-05-08	Autumn-Winter 2020	src alt ./_assets/sdf2d.jpg SDF-2D browser demo with soft lighting effects.	graphics web systems	3	Library author	TypeScript WebGL WebGL2 Signed distance fields Dynamic shader generation	Browser library, mobile-targeted, real-time on consumer GPUs, both WebGL1 and WebGL2 paths	An NPM package and BSc thesis; the renderer behind the decla.red multiplayer game	recruiter-relevant	label url NPM package https://www.npmjs.com/package/sdf-2d label url Video https://www.youtube.com/watch?v=K3cEtnZUNR0 label url download BSc thesis /media/downloads/sdf2d-andras-schmelczer.pdf true	type src alt caption image ./_assets/sdf2d.jpg Browser demo page showing SDF-2D scenes rendered with soft lighting effects. SDF-2D shipped as a TypeScript library, not a one-shot demo. That distinction shaped most of the design.

Winter 2020, BSc thesis deadline closing in, and the thing had to run acceptably on my advisor's laptop the day he graded it. That single shipping pressure exposed every lazy assumption in the architecture and picked the design: tile-based passes, deferred shading, shaders generated per scene and per device. A 2D ray tracer in the browser via signed distance fields: soft shadows, smooth reflections, no triangle mesh. The other half of the thesis was decla.red, the multiplayer game that proved the renderer survived a real game loop.

What "mobile GPU" actually meant

A 2D SDF ray tracer is conceptually simple: for each pixel, march along a ray, sample the distance field, accumulate light. The implementation that works on a desktop NVIDIA card spends so much per pixel that a mobile GPU melts. So the design problem was never "can SDFs do soft shadows" (yes, easily), it was "what work can I avoid per pixel without giving up the look."

Three constraints did most of the design work:

• WebGL1 and WebGL2 both supported. No "modern browser only" cheat. That ruled out anything that needed compute shaders or storage buffers.
• No per-scene hand-tuned shader. This is a library; users plug in their own scene descriptions. The renderer has to compile something appropriate at runtime.
• Acceptable on a phone. Not "good when the user owns the right hardware." It had to be acceptable on the laptop my advisor used to grade the thesis.

How it actually runs

• Tile-based rendering. Group pixels and reason about them together. Most regions of a frame share the same nearby geometry, so you can early-out enormous swathes of pixel work if you know the tile's bounds. This was the single biggest perf win.
• Deferred shading. Separate "find the surface" from "shade the surface." Shadow casting and reflections need the same geometry queries; doing them once per pixel and reusing the result was worth the extra texture bandwidth.
• Generated shaders per scene and device. If a scene has no reflective surfaces, the generated shader doesn't carry the reflection path. If the device only supports WebGL1, the shader doesn't reach for WebGL2 features. Static feature flags do this badly; runtime generation does it well.
• TypeScript scene descriptions, no DSL. I prototyped a small DSL for SDF authoring and threw it away. Pride's expensive. Users describe scenes in plain TypeScript and the library compiles them down. A DSL would have meant one more language to teach and one more compiler to debug.

Held up, didn't hold up

• Held up: the mobile constraint forced structural perf work instead of cosmetic perf work. When something only runs on a desktop GPU you mistake headroom for good architecture, and the rude awakening comes from a user.
• Held up: keeping the library boundary clean. A demo can hide a messy implementation; a published package can't.
• Didn't: I had no instrumentation around shader variants. Today I'd ship a small ?debug=1 overlay that prints exactly which shader got compiled for that session and why.
• Didn't: the docs are words about ray marching. The ideas are visual; the explanation should have been too. Diagrams next time.