erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions

docs(issues): #464 — the arch is cell 0x109's far wall fourteen metres beyond the open face; farther cells show over it (alpha-flush vs Z-clear order is the prime candidate)

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-09-03 22:47:48 +02:00
parent 2f7f45c2dd
commit f2c2cdb876
1 changed files with 2 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/ISSUES.md
View file

@ -117,6 +117,8 @@ then `/teleloc F4180113 39.502899 19.589222 181.119247 1 0 0 0`, zoom out, tilt
**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. **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.
**The arch located (lead, 2026-09-03 22:55, DAT):** the gothic arch in both screenshots is NOT a doorway at the stairwell's open face; it is the far wall of the corridor cell `0xF4180109` (world y 24 → 38, z 181.9 → 190.7, the cell the front-view eye sat in), fourteen metres beyond the open face: `0x109`'s near face at y=24 is its three EXIT portals (polys 0x1E/0x1F/0x20, local y=+12, facing the stairwell's exits on the same plane), and its far wall at world y=38 is fourteen wall polygons `0x0000`–`0x000D` (local y=−2.0, world normal (0,−1,0), i.e. FACING the stairs, single-sided, `emitPos=True`) around the nine-vertex arch portal `0x1D` into `0xF418010E`. Retail's solid wall above the arch is `0x109`'s polys `0x0000`/`0x0001` (z 188.9–190.7) and beside it `0x0008`–`0x000D`; the vault is `0x109`'s ceiling. Acdream draws `0x109` too (it is the FIRST hall group, `DC pv=1 n=1: f4180109`), yet content from the farther cells (`0x10E`'s columns and vault through the arch, `0x108`/`0x10B`…) appears ABOVE and BESIDE the arch where `0x109`'s far wall should occlude it — so some draws land there after the wall's depth was cleared or without a depth test: candidates, in order of likelihood, (H1) delayed ALPHA subsets flushed AFTER the gated Z clear instead of before it (retail flushes at `PView::DrawCells` @0x005a4872 BEFORE the stamp/Z clear; acdream's `FlushFartherThan` approximation, AP-34, can leave entries for a later flush) — S4-c2's exact territory; (H2) cell draws under a building-portal view not clipped to that view (the per-cell clip machinery S3 deleted as dead; retail's `PView` clip) — would spill content outside the doorway outline but not through an occluding wall; (H3) another depth-state difference. The pink quad = clear colour showing where nothing was drawn after a clear. The retail alphadepth frame's event order (FL sites vs seals) and acdream's replay order are being compared; pixel attribution at the scripted tilt decides.
## #463 — Soak `turn` samples can report a 0.1 ms GPU p50 (the turn window catches non-world frames) ## #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. **Status:** OPEN — found 2026-09-03 by the Campaign OVERHAUL v2 S3 review's perf re-measure.