In the last post I switched off skipping hidden splats, because the table it read was baked from one eye at head height and the lookup ignored how high the camera was. I said the speedup was gone until the table knew about height. Later the same day it started to. As I write this the change is on the preview build, on by default, and not on the live site.
The fix is a second bake over the same standing cells, from 6 metres instead of 1.6, with each row now carrying the height of its eye. Up to half a metre above the 1.6 metre eye, the lookup uses the 1.6 metre row. From there to half a metre above the 6 metre eye, it uses the union of both rows, so a node seen from either eye is kept. Higher than that there is no row and nothing is skipped. Skipping at the draw only turns on where both bakes load and agree on their cells. I baked 10 of the 11 places and checked each one cell for cell against the 1.6 metre bake it has to agree with. Perry Road has no collider here, so it keeps the old behaviour, where hidden parts are only drawn at lower priority.
The evidence is thin and I want to say so, because thin evidence is exactly what went wrong last time. I have looked at it once, at the La Sarraz walk spawn on an Intel UHD 620: 31 per cent of the splats in view skipped, no holes in the frame, no errors. Last time the problem only showed up when moving, so this one spot does not settle it. The eye is still sampled at two heights with a union between them, and a camera at some height between them could still find a case neither eye saw. Until it has been flown around in every place, I would treat it as a change that has not failed yet.
The other change is about what the shadow costs. With shading on, the projection step wrote 16 bytes per visible splat every frame, a centre and a normal, for millions of splats, and the draw read them back. Only lamps use the normal. With the sun’s shadow alone, which is now the default, the renderer is built without that buffer and each splat recovers its centre from its own clip position, through the inverse view-projection written per view. Folding the shadow into the projection instead looked cheaper, and it would have been wrong: a still camera reuses the previous projection, so the shadow would freeze while the car moved under it. I have not benchmarked this one yet, so I cannot tell you what it saves.
One more thing, and it is not rendering. Right now a game mechanism is being built. Until now a place here has been somewhere to be: you can drive it, walk it, ride it, fly over it. This is the work on giving you something to do there. There is nothing to show yet and I do not know exactly what it becomes, so I will not describe it past that. When something exists, it will land here the same way everything else does, including the parts that do not work.
I am working very hard on this. That is not a figure of speech: there have been more than 1,300 commits since the first one in May, and 210 of them came in October alone, while the site was also falling over under more visitors than it had ever seen. Those weeks went into fixing what you found, and into the renderer work above. The mechanism gets the same effort now, because a place you can stand in is only the beginning of what I want this to be.