97b98b15af
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
m3ultra
|
f0b9a1d30f |
Lane B R39 (Fable's ruling): the magpie takes E's GLB use-if-ready, and the fallback's white moves
+1 draw / +894 tris with the bird on screen, +0 with it off — measured same page, same frame, by toggling the InstancedMesh count. ?noassets keeps the 182-tri procedural bird (+1 / +182), so this is furniture.js's use-if-ready SECOND path, not a substitution. state.asset reports which bird is bound. THREE THINGS MEASURED BEFORE THIS WAS SAFE, AND ALL THREE WOULD HAVE SHIPPED WRONG: · E's bird faces +Z and this file flies -Z (Matrix4.lookAt's -Z column is the travel direction). Sliced the GLB's 894 tris along Z in ten bins: +Z end mean y 0.31, half-width 0.009 (head + bill); -Z end mean y 0.028 (tail). Without rotateY(PI) the magpie swoops TAIL-FIRST. This is the FIFTH -Z/+Z instance and the first caught BEFORE it shipped — because R39's lineage table said to point a measurement at it. Verified in pictures: perched head-leading, and a swoop frame taken head-on. · Its origin is at the FEET (GLB law minY=0) while PERCH_Y is a body-centre height: dropped 0.20 m so it stands on the lamp arm (4.12) instead of hovering. `folded` is 1 for the GLB — it IS the perch. · THE FETCH IS ARMED BY createMagpie(), NOT BY THE IMPORT. index.html imports this module unconditionally and gates only the CONSTRUCTION, so a module-scope loadGLB (furniture.js's shape) would have put a brand-new GLB request on the ?classic=1 boot — a fetch delta on the one boot that is not allowed one. Asserted on the network log, not on the code: default 1 request (asset 'glb', 894 tris) · ?classic=1 0 · ?magpie=0 0 · ?noassets=1 0 (asset 'primitive', 182). AND ONE MY EDIT INTRODUCED INTO ANOTHER LANE'S TOOL: a module-scope loadGLB also fires GLTFLoader's fetch path under node, so Lane E's pipeline/dump_bird.mjs (which imports this module unmodified) died with "ProgressEvent is not defined". Gated on IN_BROWSER as well as ?noassets; E's tool then ran against my edit and reported 182 triangles / 216 verts — the placement fixes are exactly +0 tris. THE FALLBACK, FIXED AND THEN MEASURED — a half-win, stated as one. E is right that the white bars sat 3 mm ABOVE horizontal wing planes, so from below (the player is always below: perch 4.32 m, EYE 1.62) the black wing occluded its own flash: bar y 0.048 -> 0.042. Same class of fix, my own arithmetic, for the other two marks: the nape was BURIED IN THE HEAD (head-sphere surface at z=-0.10 is y 0.0728, the box topped out at 0.067) so it moved behind the head to z -0.07; nape and rump thickened 0.014->0.030 and 0.02->0.034, because from the flank a 14 mm slab on a 166 mm bird is 1.3 px at 64 px. All +0 tris. Measured in the same crop of the same pose: pale area 180 -> 399 px, dark 3,017 -> 2,755 — but TRUE white 33 -> 28, because a downward-facing surface gets no sun. E's GLB reads 755. The fallback cannot be made pied with primitives at zero cost; the problem is photometric as well as geometric. Stale comments corrected: magpie.js:9 and :123 said 154 triangles; it is 182 (E's ask 1). FILED, NOT FIXED: the arcade's awning posts land +/-0.50 m from the centreline — two rows 1.00 m apart, 34 posts down a 5.00 m lane (my own measurement from the plan, confirming E's). AWNING_DEPTH 2.2 is tuned for a 9 m footpath. One clamp fixes it, but it changes default-boot geometry for a district whose whole treatment is a scheduled item, and the post line should be designed with the roof. Lane E's transmission recall checked, not assumed: longbench, streetlight and magpie as staged in web/assets/models/ carry no KHR_materials_transmission. My lane wires neither of the first two today. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
m3ultra
|
a982f3ce67 |
Lane B R39 (Fable's ruling): THE SIGN — +sin lands; the fourth instance of the -Z/+Z confusion
index.html:428 (Lane D's patronage door points, since R8) and :500 (doorOf, the R32 cluster-pose
spawn) computed the shop front as (-sin ry, -cos ry) — the BACK of the building. buildings.js:410,
:583-597 put the facade, the door and the doorRect at local +Z; dbg.js:53 says so in words;
minimap.js has always drawn its front tick there. Two characters, both sites.
THE PATRONAGE DOOR POINT, on the footpath (registry.js's own roadWidth/vergeBand split, outside the
carriageway, outside every lot):
synthetic 0/493 -> 427/493 median 26.22 m -> 9.40 m from the centreline
katoomba_real 0/72 -> 67/72 19.10 -> 3.90
fitzroy_real 0/139 -> 139/139 19.10 -> 3.90
bowral_real 0/30 -> 28/30 21.10 -> 5.90
Not one door point in the corpus was on a footpath. Lane D's peds ducked into the back fence.
THE SPAWN, booted code both sides (:8702 the fog commit, :8701 the fix, nothing monkey-patched):
synthetic (25.5,-17.9) 3 shops within 25 m, 0 in front, 0 discovered
-> (6.1,-19.8) 4 within 25 m, 4 in front, 4 discovered
katoomba (-219.0,-471.3) 3/0/0 -> (-200.0,-474.4) 4/4/4
And in the picture (docs/shots/laneB_r39/sign-*): katoomba's shipped boot opens STANDING IN A
PADDOCK FACING THE BLANK BACK WALL OF A BUILDING — the R31 playtest's own complaint, the one R32 was
written to fix and, because of the sign, never did.
NO GOLDEN MOVES: SPAWN and the patronage points are runtime pose, computed in the shell from a plan
it never writes. Lane A selfcheck either side: fingerprint 0x5f76e76 -> 0x5f76e76, 157,647/157,647.
?classic=1 never enters the branch and keeps the frozen (-96, 9) pose.
-> LANE F: the R32 cluster-pose spawn gate and the R35 first-five-minutes smoke both photograph this
pose and need re-baselining. The falsifiable arm that needs no picture: at spawn, the count of shops
within 25 m that are IN FRONT of the player must be > 0 (0 on 4/4 towns before, 4 on 4/4 after).
THE LINEAGE, written down as Fable asked — this is the FOURTH instance of the same confusion:
R13 RY_FLIP (the band 180 deg off) · R15 the venue poster on the back wall (15.9 m from the facade,
0.07 m from the back) · R27 every real-town shopfront facing the paddock (dot = -1.000 on 35/35 and
72/72 lots; CITY_SPEC:71 says -Z, :335 says +Z) · R39 these two. Every time the rig/pose convention
is local -Z and the visible front is local +Z, and every time it was caught by a PICTURE or by a
consumer with a different convention — never by a metric. A heading has no falsifiable arm inside
the file that computes it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
m3ultra
|
0ee7a84710 |
Lane B R39 39.2: THE FOG — the map shows what you walked past, and is finally readable
minimap.js drew every lot in the plan from the first frame (493 shops on the synthetic, one M press, against 5,330 m / 4.8 game-days of walking to earn it). It now draws what has been walked past AND FRAMES ITSELF TO IT — a shop lot goes 0.83x1.11 px -> 29.4x39.2 px on bowral_real, 35.3x. ZERO DRAWS, measured as an A/B: two port-isolated no-store servers, HEAD vs treatment, the same 15 stations x 4 yaws compared as JSON before either sweep runs. Draw calls IDENTICAL on 60/60 samples at noon and at night; with the gig layer off both sides (the venue queue's async rigs were the only noise) NIGHT is identical in draws AND triangles. Map mode cannot cost a draw structurally: the frame loop never calls composer.render() in the map branch. - discovery.js (new): a 25 m PROXIMITY PROBE, not onChunkBuilt (R=2 => the outermost live chunk corner is 181 m out), on a plan-derived spatial hash — 1.09-1.37 us a probe, every 6th street frame = every 0.46 m at WALK. Plus a side test: you must be in FRONT of the shopfront. Control with a red arm: walking the synthetic's two service laneways, radius-only reveals 93 shops, the shipped probe 59 — 34 refused through the back wall; on the arcade it refuses 0 of 17. - save.js: optional `known` block under the delta law, keyed by TOWN (re-derived: 23 caches x 3 seeds, shop/edge ids and lot geometry all identical; the synthetic alone keys @<seed>). Bounded by the plan (max 493 shops / 2,593 edges) at 8,192, 64 towns FIFO, ints only. Whole corpus fully learned = 137,547 B (2.6% of quota); 482 B after a 500 m outing. Eight reject arms demonstrated. - classic BY CONSTRUCTION: createMinimap(plan, null) is the pre-R39 map and the file has no flag test at all. ?classic=1 / ?fog=0 / ?game=0 map canvases are hash-identical to HEAD's. - Lane A's address layer consumed (getTownCache + createAddresses): street names along walked streets, deduped; the synthetic gets district labels from the same line. No town-type branch. FILED, NOT FIXED: index.html:384 (Lane D patronage door points) and :450 (the R32 spawn) use (-sin ry, -cos ry) — the BACK of the building. buildings.js:410/583-597, dbg.js:53 and minimap.js all use local +Z. Measured against each lot's own frontEdge the +sin point is 0.00 m from the kerb and the shipped one 15.25 m the wrong side, 493/493 and 72/72 shops. At the shipped spawn 0 of the shops within 25 m are in front of you on all four towns tested; at the corrected one, all of them. Two characters, but it moves the default boot's opening pose mid-round — Fable's call. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |