From 2f7f45c2dd5fc0caa36ee28c7df987c3ee401875 Mon Sep 17 00:00:00 2001 From: Erik Date: Thu, 3 Sep 2026 22:45:07 +0200 Subject: [PATCH] =?UTF-8?q?docs(issues):=20#464=20geometry=20round=20?= =?UTF-8?q?=E2=80=94=20punches=20vertex-identical=20to=20retail,=2012=20of?= =?UTF-8?q?=2016=20rejected=20by=20the=20=C2=B112=20rule=20in=20both=20cli?= =?UTF-8?q?ents;=20no=20authored=20wall=20above=20the=20arch?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Fable 5.1 --- docs/ISSUES.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 8991f903..dd461695 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -115,6 +115,8 @@ then `/teleloc F4180113 39.502899 19.589222 181.119247 1 0 0 0`, zoom out, tilt **Gate replay (lead, 2026-09-03 22:29, scratch worktree `s4-c1-gate` at the S4-c1 fix-round commit `2bd353234` with the capture copied in and a fifth `[Fact]` added):** `AlphaDepthTranscript_CathedralStairArch_MatchesRetailFrame2` **PASSES** — acdream's PM (mode, counterBefore) and PC (ov, counter, forceClear) sequence at the artifact pose is EXACTLY retail's: the sixteen building-portal punches, the eight exit seals, the counter. So the divergence is NOT which punches/seals happen or their order; it is their GEOMETRY on screen (what each punch fan covers, what each seal writes) or the building shell's depth at that face — the transcript gate cannot see either. AD-17 records the one known geometric deviation exactly there: a >8-edge or multi-polygon OUTSIDE view (the stairwell's open face IS multi-polygon: three exit polys of `0x114` + two of `0x113`) yields a zero-plane slice and that view's punch fans draw UNCLIPPED, while retail CPU-clips every portal polygon exactly. Next: compare the punch-fan geometry per portal against retail's clipped polygons (retail's `DrawPortalPolyInternal` clips the polygon against the current portal view's planes before drawing; a vertex-dump capture at the pose, or the replay harness's own clipped polygons, gives the retail-side outline) and check that the cathedral's shell is drawn with depth before the punches. (Side finding of the same replay: `AlphaDepthTranscript_TerraceEdge` FAILS at `2bd353234` — see the S4-c1 fix-round record.) +**Geometry round (lead, 2026-09-03 22:36–22:45):** a new retail template (`oh-capture-pm-verts.cdb.template`, `cathedral-stair-arch.pmverts.log`, 3 frames) prints every `DrawPortalPolyInternal` attempt's vertices; the scratch replay (`s4-c1-gate`, a `PunchGeometryDump` fact over the same harness) prints acdream's. Result: 16 attempts per frame on both sides, VERTEX-IDENTICAL (e.g. retail poly `12980fd4` = acdream building `0xF418000C` view 1: `(4.5018, 11.924, 21.8948)` …), and applying retail's own reject rule (every vertex on ONE of the x=±12 / y=±12 planes) to retail's list rejects 12 of the 16 — exactly the 12 acdream drops between collect and replay (`COLLECT punches=16 REPLAY fans=4`). The rejected 12 are the five of building `0xF418000B` and the seven of the HALL building `0xF418000A`, all on local y=12.000; the four drawn are `0xF418000C`'s at y=11.924. **So the hall's doorways are never punched in either client, and the punch geometry is not the divergence either.** The DAT then rules out a missing wall: the tower shell `0x01001FB7` (local y −10.165 … +10.165, z 0 … 53.7; 363 render polys) has NO polygon with a ±y normal on its far face above z 21.9 (only `poly 0x000B` at z 20–21.9), and the hall shell `0x01001FB3`'s +y face at local y=12.0 (the same world plane y=24.0) has none above z 21.9 either; the hall cell `0x109`'s near face on that plane is itself an EXIT portal at local y=+12. Nothing authored stands in the region above the arch. **Therefore the solid wall retail shows there is produced by the outside-view block's depth/colour ORDER — what is on screen in that region when the exit views are sealed and the interior is repainted (the gated Z clear, the `FlushAlphaList`/stamp, the seals, the repaint), not by a polygon we fail to draw.** Both event streams (PM/PC) match retail exactly, so the difference is in what each event DOES to the framebuffer. Next: pixel attribution at the tilted pose (which draws touch the region above the arch, in order, with their depth states) — a scripted tilt (the `mouselook` automation verb, in flight) plus a RenderDoc or recording-device capture; then the retail-faithful analysis of the diverging step. + ## #463 — Soak `turn` samples can report a 0.1 ms GPU p50 (the turn window catches non-world frames) **Status:** OPEN — found 2026-09-03 by the Campaign OVERHAUL v2 S3 review's perf re-measure.