Living
Image
Turning a still architectural render into software you can explore. How it's built, and why the prompt is the product.
Customers stop receiving images. They receive an application.
A render is a file. It captures one hour of one day, then it's finished. The building it depicts will stand through every hour for decades.
Living Image makes the render run. The customer opens a link and makes real-time environmental decisions inside the visualization: moving the sun, reading the shadows, watching the windows come alive at dusk.
They export any moment as a still, or the whole day as a timelapse.
One moment, sold as the whole building
Every variation is a new invoice
A different time of day means re-opening the 3D model, re-rendering, re-delivering. Days of turnaround. The economics punish exploration.
The deliverable is mute
Once the file is sent, the sender learns nothing. Which view resonated? What did the client actually study? A static image never says.
One render, the entire day
Upload once. The customer explores the full arc from morning to night, and exports whatever they need from it.
The first approach hit a wall
Vibe coding a mockup with Claude, the plan was real-time relighting in the browser: segment the image, estimate depth, drive WebGPU shaders from a solar model.
The model could not produce the deterministic shading techniques a viable prototype required. Shadows didn't move correctly. Highlights sat wrong. The result was closer to colour-grading than rendering.
Stop rendering light. Generate it, twelve times.
The reframe: don't compute lighting in real time. Send the same image through an image-editing API twelve times, once per hour, and let the browser crossfade between the results.
The entire pipeline collapsed. No segmentation. No depth estimation. No material classification. The frontend became a stack of layered images with opacity interpolation.
Twelve frames, one continuous day
The browser crossfades the stack in real time. Shadows swing, the sky shifts, and the windows warm as the sun drops below the horizon.
All of it driven by a single slider — the same control moving the light behind this page.
Twelve renders of twelve different buildings
AI image generation drifts. Ask for the same building twice and you get two interpretations: a window shifts, a mullion divides differently, vegetation reshapes, a facade panel changes texture.
Crossfade between two frames that disagree about geometry and you get ghosting, morphing, and double vision. The illusion collapses instantly.
Twelve outputs, one building
Every frame must be pixel-consistent in geometry and differ only in light.
Which makes prompt writing the entire engineering problem. Not a wrapper around the product. The product.
Determinism through constraint, not creativity
morning light."
Sun elevation 30° from the east.
Shadows fall west-northwest at 2× object height.
Colour temperature 5500K.
PRESERVE. The EXACT building geometry,
window positions and divisions, materials,
textures, vegetation, camera angle, composition.
PERMIT. Only modify: sun position and
lighting direction, shadow angles and lengths,
sky gradient and brightness, ambient colour
temperature, surface light reflections.
Why this produces the same building every time
Physics, not mood
"30° elevation, shadows at 2× height, 5500K" is verifiable. "Morning vibes" is not. Numbers give the model a target it can hit consistently; adjectives give it room to improvise.
Exhaustive invariant enumeration
Hallucination fills gaps, so the prompt leaves none. Geometry, window divisions, materials, textures, vegetation, camera, composition are each named explicitly. Anything unnamed is something the model may feel free to reinterpret.
A closed permit list
Rather than only forbidding, the prompt states the complete set of permitted changes. Five things may move. Everything outside that list is implicitly frozen, converting an open creative task into a bounded one.
One skeleton, twelve instances
All twelve prompts are the identical template. Only the hour, the solar elevation, the shadow vector, and the Kelvin value change. Consistent structure in, consistent structure out.
The prompt is fed by real astronomy
Those elevation angles and Kelvin values aren't estimated. They're computed from a solar position model: latitude, hour angle, and seasonal declination, validated in Python against real sunrise and sunset tables.
The same model drives the browser, so the slider passes through civil and nautical twilight, golden hour, and high sun at the times they actually occur.
sin(lat)·sin(dec) +
cos(lat)·cos(dec)·cos(hourAngle)
Upload once. Explore the day. Export anything.
Drop the render
A single still image, dragged into the browser. No 3D model, no plugin, no setup.
SenderGenerate the day
Twelve hour-specific prompts fire in parallel against the image API. Each returns the same building under different light.
SystemMove the sun
One slider crossfades the stack in real time. Shadows swing, sky shifts, windows warm as the sun drops.
End userExport
Any single moment as a still, or the entire arc as a timelapse animation.
End userThe experience is authored, not open-ended. The end user never writes a prompt. They explore inside the range the sender generated, which keeps every frame on-brand and quality-checked.
The stack
FastAPI + adapter layer
A shared interface across three image models, so any backend can be swapped without touching the product. Twelve calls dispatch in parallel with progress tracking.
WebGPU crossfade
Layered image stack with opacity interpolation, procedural sky, window illumination and tone mapping in WGSL. 60fps on integrated graphics.
Test-driven
42 tests written before implementation, covering prompt generation, adapter contracts and server endpoints.
Decided by evidence, not preference
Rather than pick a provider on reputation, the harness runs the same architectural render and the same twelve prompts through Gemini, GPT-4o and Grok side by side.
The measure that matters is structural fidelity: how far the geometry drifts across twelve generations. That single number decides the backend.
IC-Light in reserve
A relighting model built specifically to preserve structure. The adapter pattern means adopting it is a configuration change, not a rewrite.
Time of day is the MVP, not the product
Fidelity validation
Run real architectural renders through all three models and measure geometry drift across the twelve frames.
Curation and instrumentation
The sender chooses which components to expose, shares a link, and sees how the client explored it and what they downloaded.
Weather, seasons, street life
The same authored approach extended to rain and snow, seasonal light, and animated street scenes. Then spatial depth and parallax.
Each addition is another environmental decision the customer can make inside the visualization, and another reason the deliverable is an application rather than a file.
One image in.
An application out.
The render stops being the end of the conversation and becomes the start of one.