Making Today's Rock
Today's Rock started from a deliberately small question: what if a website made exactly one object, gave that object to everyone, and refused to keep it?
The implementation followed the same constraint. The project does not need a content management system, a daily publishing job or a collection of downloaded models. A static page can contain the rules, and a visitor's browser can perform the rest.
Start with one strong rule
The most important design decision is not a technical one. It is the rule that there is only one rock at a time.
That rule eliminates a surprising number of familiar website features. There is no randomise button, because randomness would give different visitors different objects. There is no account system, because the rock is not meant to belong to a person. There is no favourite button, because the site is not building a collection. There is no archive, because yesterday's object is no longer today's object.
Once those constraints were accepted, the rest of the design became much easier to keep small.
Why a rock?
A rock is ordinary enough to be almost anonymous. It has shape, colour, weight and surface, but it does not arrive with a built-in narrative that tells the viewer what they should think about it.
The museum placard supplies a little unnecessary seriousness. The object is given a name, a supposed composition, an approximate mass and a provenance, as if a tiny institution had spent resources cataloguing something nobody needed to catalogue.
That contrast is the tone of the project: solemn presentation for a completely unnecessary object.
Why generate it instead of modelling it?
A hand-modelled rock could have been used, but it would turn the daily change into a collection of authored assets. Procedural generation makes the date itself part of the artwork. The rock is not selected from a library; it is constructed from the day's seed.
It also makes the shared property precise. A particular date maps to a particular set of generation decisions, so there is no ambiguity about which rock belongs to that day.
Why keep the renderer small?
The site could have used a general-purpose 3D framework. Instead, the current renderer performs the relatively narrow job it needs itself: generate a triangular mesh, transform it, sort its faces by depth, calculate simple lighting and paint the result to a canvas.
That keeps the project dependency-light and makes the source easier to inspect. The page is not trying to be a reusable 3D engine. It is a small machine for making one particular kind of object.
The visual language
The surrounding interface is intentionally restrained. The background is warm rather than pure white, the typography mixes a quiet serif with a small uppercase sans-serif label, and the placard is treated like a physical museum card rather than a software control panel.
The restraint matters because the rock should remain the visual event. Interface elements explain what is happening without competing with it.
The interaction
The basic interaction is deliberately obvious: drag the rock to turn it over. When the visitor stops interacting, the object can continue a slow automatic rotation. On touch screens, the same surface supports dragging and a two-finger gesture for zooming.
The site does not bury the object behind controls. There is no settings panel, camera menu or collection interface because none is needed to understand the work.
The placard came from the same constraint
The generated text is not intended to simulate a real geological database. It is a curated vocabulary that is recombined deterministically. Names such as “The Reluctant Fragment” sit alongside descriptions such as “A small hole, purpose unknown” and “Origin: undisclosed.”
The approximate mass is the one numerical field that is generated continuously rather than selected from a fixed phrase. It is explicitly labelled approximate, and the joke is that the site has apparently bothered to weigh something while simultaneously declining to preserve it.
Why the site changes at UTC midnight
The artwork needed a single global transition. Local midnight would split the audience across time zones, while a server's publishing schedule would introduce unnecessary infrastructure. The browser already knows the current UTC date, so the simplest solution is for the page to calculate the next UTC midnight and regenerate the specimen when the date changes.
What the project deliberately leaves out
- No public archive of previous rocks.
- No user-specific rocks.
- No database of generated specimens.
- No API supplying the day's model.
- No stock imagery standing in for the generated object.
- No conventional content feed pretending the project needs daily articles.
These omissions are not merely technical simplifications. They protect the central idea from turning into a more conventional website.
Keeping the source visible
The project is small enough that its implementation can be inspected directly. Publishing the source is useful for the same reason the technical explanation exists: the interesting part of Today's Rock is not only what appears on the screen, but the set of rules that makes that appearance happen.
View the Today's Rock source on GitHub
What might change
Small improvements to accessibility, browser compatibility and the clarity of the documentation are compatible with the project. Features that turn the work into a catalogue are not.
The useful test for a future change is simple: does it make the single daily object more understandable or enjoyable, or does it merely make the website bigger?