Dressing a roadside

On a fast road, the trees, signs, barriers and grandstands beside the track are not decoration. They tell you a corner is coming, how hard it is, and where to brake. Take them away and the same road becomes unreadable at speed.

So the demo is given two things. A spec — rules with numbers in them: how much stuff, how far off the road, what must stay visible from the cockpit, what has to stand before a corner. And a vocabulary — the objects it may use, described as sizes and habits.

Then it dresses a road it has never seen, and every rule has to come out true.

A rule that says “a barrier 4 metres from the edge” is a rule about one road. Said in half-widths — call it W, half the distance across the tarmac — it is a rule about every road. That single choice is what makes the whole spec portable: point it at a wider track, or a longer one, and nothing has to be restated.

pcg-ts is a node graph: little boxes that each do one thing to a pile of points, wired nose to tail. This demo's graph is about twenty nodes, and it has exactly two jobs — turn the given centreline into a road surface, and write the s / t / h / W coordinate system onto every point of it so that anything downstream can speak in road-widths.

Worth saying plainly: the graph does not place the scenery. The placement rules are ordinary TypeScript that cooks the graph, reads the lap back, and works out a list of things to stand beside it. The graph's own roadside row — two evenly spaced lines of points — is a deliberate placeholder, kept only so the seam between “where the road is” and “what stands beside it” is already cut.

The demo reads one data file, demos/racetrack/vocabulary.json. Think of it as a parts list: each object described as a handful of axis-aligned boxes, plus how that kind of object behaves — how far off the road it stands, how high, how often, which side, whether it prefers corners or straights.

Each entry also carries a set of poses, and they are the reason the dressing does not look stamped. The vocabulary carries no rotation, so the demo chooses one — but every pose keeps its own boxes, and 362 poses give 361 distinct sets. The variety is in the shapes.

A rule like “35% of things sit in the mid band” is a distribution. You can satisfy it while placing, by picking each object with the right odds. A rule like “the driver must be able to see the next stretch of road” is a threshold. No amount of careful dice-rolling guarantees it, because it is a promise about the result, not a shape of the results.

Thresholds get a repair pass: place first, then measure, then move or drop the offenders. Getting this backwards is what makes a rule set look self-contradictory when it is only being applied in the wrong order.

Nine stages, and they only work in this sequence. The cull sits sixth rather than fourth — everything the legibility rules add has to face the visibility test too, and a corner marker is exactly the tall thing near the racing line that the test exists to catch.

Every repair reports how many times it had to fire. A repair that never runs and a generator that never needed one produce identical green tests — so the count is part of the output, not just the pass.

Two failures worth remembering, both found by looking at the screen rather than at the tests. A repair that keeps handing work to the next repair never settles — trace what each round actually moved before blaming the rules. And a repair that cannot recognise its own no-op will fire forever on a rounding error: a height of 1.2 that comes back as 1.1999999999999997 looks like a thing that still needs fixing.