about
Nothing But Datacenters
A 30-minute, two-channel generative work, and the public record of how it was made. The artwork lives on reillydonovan.com; this site carries the machinery.
The work
An image of a data center is fed back into an image model tens of thousands of times, each frame becoming the input for the next. Nothing is drawn by hand. The picture drifts — geometry loosening, structures giving way — and then, at intervals, snaps back. The model keeps recovering the building. It cannot stop producing the thing it was asked for.
Data centers are the most physically demanding infrastructure of this moment — measured in gigawatts, in aquifers, in farmland converted to windowless halls — and we have agreed to call them the cloud. That word does the work of making a building disappear. Here the disappearance is not a metaphor but a procedure, running at twenty-four frames per second, performed by the same class of system the buildings were raised to house.
Across thirty minutes the two channels begin from identical conditions and drift apart, each finding its own rhythm of collapse and recovery. What the work finally holds is not the image of a data center but its persistence: a form the machine returns to no matter how far the picture strays.
How it was made
One GPU — NVIDIA GeForce RTX 3090 Ti — running a continuous img2img feedback chain, roughly 5.9 seconds a frame across 43,200 frames. Every frame is the input to the next. Nothing is composited and nothing is re-timed.
The schedule is written before the render starts: one prompt line per frame, on a viewpoint axis that cycles aerial, front, side and three-quarter. The image channel was conditioned on each line plus a suffix the text channel never shows. You can read the whole schedule, frame by frame.
The second channel is that prompt rendered as text, frame-locked to the image by being produced in the same driver iteration. Two independent stacks — separate sequences, directories, hashes and manifests — never composited.
It took three runs. Two ended badly: a Windows Update restart at frame 2,651, and a socket exhaustion bug at frame 10,636. Both are in the record, with what each cost and what was recovered. So is the fact that the driver binary changed mid-pass. The pass record holds all of it.
What this site is
A record, not a portfolio. Two systems with one boundary: the project record knows what the work means and emits a structured file; this site knows what that file looks like. Change the record and the exporter changes. Restyle the site and the record never notices.
Everything here is generated and none of it is hand-written, which is the only way a record stays true to a render that is still moving. When the render moves, one command refreshes every figure on every page.
- record generated
- 2026-09-15 22:52-07:00
- project created
- 2026-09-09 02:15-07:00 by the render node
- passes updated
- 2026-09-15 01:19-07:00
Every figure on this site comes from one generated file, and that file is published too: record.json. It is there so the record can be checked rather than taken on trust — the render environment is withheld from it, and the file says so.
Not published
The render log holds the prompt, sampler seed and applied denoise of every frame. That is a complete reproduction recipe, so the schedule and the summary statistics are here and the seeds are not. Available on request.
The project is 244 GB and the 30-minute ProRes master is 32 GB. Frames and masters are named, sized and hashed throughout this site, never copied into it.
Review encodes of the published prefix of a pass. Disposable and regenerable from frames; NOT the deliverable encode. The frame range is in every filename so a partial preview can never be mistaken for the whole pass.
Every frame of a feedback loop is substantially new, so inter-frame prediction buys almost nothing. A delivery codec on defaults measured PSNR 21 dB against source; ProRes 4444 measures 51 dB.