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

docs(#185): root cause = synthetic sliding-normal at a convex tread edge (#137/TS-4 family, artifact not geometry)

Browse source
This commit is contained in:
Erik 2026-07-08 07:28:35 +02:00
parent 29e01c3829
commit 99c22fad48
1 changed files with 14 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

22
docs/ISSUES.md
View file

@ -74,14 +74,20 @@ above the jam (more 38.7° treads → a flat porch at Z 63.6) — so it is ONE l
not a general stair failure. Classic **#137 / building-collision-mesh junction-anomaly family** not a general stair failure. Classic **#137 / building-collision-mesh junction-anomaly family**
(TS-4 sliding-normal-provenance), stair edition. (TS-4 sliding-normal-provenance), stair edition.
**Open question (decides mesh-artifact vs faithful):** is that 52° face **real dat geometry** **RESOLVED (artifact, not geometry) — `ACDREAM_PROBE_BUILDING=1` hit-poly capture:** at the
of object `0xf6822103` or a **mesh-generation artifact** at a BSP-leaf / sub-object junction jam, ALL 156 building collisions are ONE polygon — a real, walkable **38.7° tread quad**
on our side? The capture only records treads the player STOOD on, so it can't show the jam (`gfxObj=0x01000AC5`, `obj=0xF6822103`, `partIdx=3`, local plane `(-0.625,0,0.781)`; world
face's own extent or the tread directly above it. Decisive next read: dump `0xf6822103`'s verts X 131.25–132.75, Y 77.00–77.50, Z 60.62–61.01). **There is NO riser / wall polygon in
collision faces (`ACDREAM_DUMP_GFXOBJS`, or resolve its GfxObj/Setup and decode the BSP) and the collision mesh at all.** The 52° "wall" normal from the resolve capture (`(0,0.78,0.62)`)
check for a spurious ~52° face where a 38.7° continuation should be. If the step to the next is that tread normal **rotated exactly 90°** (perpendicular; dot ≈ 0) — it does not exist in
tread is ≤ 0.6 m (the step-up budget; it looks ~0.4 m), step-up SHOULD lift the player → bug the dat. So the block is a **synthetic sliding normal fabricated by our collision RESPONSE**,
in step-up-vs-wall classification for a just-over-walkable face. not real geometry and not a step-height/budget issue: the foot sphere straddles a convex tread
edge (near a building-part seam — `partIdx=3`, neighbouring `gfxObj=0x01000ACA` present), hits
the lower tread poly, and the slide/validate chain invents a perpendicular normal, flattens it
to horizontal `(0,1,0)`, and slides the player sideways. **Confirmed #137 / TS-4
sliding-normal-provenance family** (phantom wall at a convex edge/seam), stair edition. Fix
lives in that family (where the perpendicular normal is fabricated / how a convex walkable
tread edge is handled) — touches the frozen collision internals → brainstorm gate first.
**Files:** `src/AcDream.Core/Physics/TransitionTypes.cs` (step-up / slide classification, the **Files:** `src/AcDream.Core/Physics/TransitionTypes.cs` (step-up / slide classification, the
sliding-normal horizontalisation); building-collision mesh generation (BSP faces for sliding-normal horizontalisation); building-collision mesh generation (BSP faces for