One camera for the whole tileset: nine chunky props re-meshed and ortho-rendered

9/9 through flux product shot -> trellis2_mlx -> glb_to_sprite, unattended.
Rake corrected after the first pass: tall objects need a STEEPER angle (76), not
a shallower one — an arcade at 55 is a front-on slab. Re-angled from the meshes
already on disk, no re-generation, which is the point of keeping the GLB.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

LANEHANDOVER.md

@@ -2089,3 +2089,35 @@ machines, fridges).
 front-on fridge; the strict-overhead re-roll was physically correct and visually
 dead — a grey box, because the glowing bottles that identify a fridge are on its
 front. Kept the readable one. `glb_to_sprite.py --rake 60` encodes this.
+
+## SESSION — FABLE-SOLO-25 · 2026-07-22
+
+**Branch:** main (solo, Fable) · **Gate:** lint ✓ build ✓ test ✓ (783 tests) · **Deployed**
+
+### The tileset now shares one camera
+Nine chunky props re-run through the [GLB] route, 9/9 clean, unattended:
+boothTable, barFridge, arcade, speaker, deck, dishwasher, crate, highTable,
+discoball (23–42MB meshes each). Source images are deliberately clean PRODUCT
+SHOTS, not top-downs — TRELLIS reconstructs best from a clear view of the
+object, and the game's camera angle is applied at RENDER time by the fixed
+rake. Separating "what the object is" from "how the game looks at it" is the
+whole point of the route.
+
+### I had the rake backwards, and the mesh made it cheap to fix
+First pass used a SHALLOWER rake for tall objects (55°) reasoning "show more
+face". Wrong: a tall object already shows nothing but face. The arcade and the
+speaker came out as front-on slabs. Corrected to **~76° for tall objects, 60°
+for low/wide** and re-rendered — **without re-meshing**, because the GLB was
+already on disk. That is the 3D route's real advantage in practice: re-angling
+a prop costs seconds, where flux would need a fresh generation and a fresh roll
+of the dice on camera.
+
+### Judge at ship size, not render size
+The 512px renders of the fridge looked ambiguous and I nearly re-rolled it.
+At 32x32 under the game's own point light it reads fine — venueMap LIGHTS do
+half the identifying work (fridges carry a cyan glow, the arcade a blue
+flicker). Recorded in SPACES.md so nobody burns farm time chasing a preview.
+
+### Verified in pane
+Dance floor at game scale: disco ball has real mirror-tile detail, decks show
+their platters, speakers read as cabinets, truss reads overhead. Screenshot.

docs/SPACES.md

@@ -134,7 +134,20 @@ read as one room. The mesh route renders every prop from one fixed ortho
 camera, and TRELLIS carries detail flux flattens: worn felt, real pockets,
 rails and legs, clean alpha.
 
-**RAKE = 60°, and it is not negotiable upward.** The venue's props are
+**RAKE by object HEIGHT — and I had this backwards first time.**
+Low and wide (pool table, booth table, crate): **60°**. Tall (arcade, fridge,
+speaker, anything standing): **~76°**. The instinct to *lower* the rake for tall
+objects "so you see more face" is wrong — a tall object already shows nothing
+but face; it needs to be steeper to read as a floor prop at all. A speaker at
+55° is a featureless black slab.
+
+**Judge sprites at SHIP size, not render size.** A 512px render of a fridge from
+above looks ambiguous; the same sprite at 32x32 under the game's own point light
+reads fine, because the venue's LIGHTS do half the identifying work (the fridges
+carry a cyan glow, the arcade a flickering blue). Do not re-roll a prop off the
+back of the big preview.
+
+**The old guidance, kept because it is still true for low objects:** The venue's props are
 three-quarter top-down, not straight down. Re-rolled from directly overhead, a
 bar fridge is a grey rectangle — physically correct and visually dead, because
 the glowing bottles that say "fridge" are on its front. 60° keeps the top