re: CORRECTION -- the e106 slab is a container-dependent mis-decode, not a stray volume
One iteration ago I concluded assemble_ship was drawing a non-renderable collision volume. That named the wrong cause, and decoding the same resource from every container that holds it settles it: Stage_S01 172 verts 110 tris 49 x 23 x 42 <- a turret, correct Stage_S02 172 verts 110 tris 1600 x 2100 x 4800 <- wrong Stage_S08 same 1600 x 2100 x 4800 <- wrong Stage_S26 same 1600 x 2100 x 4800 <- wrong eleven others 49 x 23 x 42 <- correct Same resource, same vertex and triangle counts, correct in eleven containers and wrong in three. So the placement is legitimate (e303_wep_01 is a small shared turret cross-mounted on e101/e106), the original author's vbase-dedup explanation of the capture's silence stands, and my "dedup would show one, not zero" objection does not survive -- at its true size the turret is ordinary geometry. The defect is in the mesh decoder. The wider point: the decoder can produce wrong geometry WITHOUT declining. The XBG7 audit counted 814 honest refusals; this is the other kind, silently 100x too large. A screen for the signature (bounds exact multiples of 50, span > 1000) flags 22-32 models each in S02/S03/S08/S26/S27, but it also catches legitimate e_rou_* composite proxies, so that is a candidate list and not a bug count. Next: diff the anchor scan's chosen vb0 for this resource between Stage_S01 and Stage_S02 -- same resource, two outcomes -- and turn whatever distinguishes them into a post-decode sanity check so a silent mis-decode becomes a decline. Kept from the previous entry: the test can only fail one way, and cross-id placement is genuinely narrow (2 pairs across 335 ships). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -153,7 +153,7 @@ report needs re-grounding against a specific ship and a specific expectation.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ The format layer is NOT exonerated — `assemble_ship` draws a non-renderable volume
|
||||
## ⚠️ The format layer is NOT exonerated — but the cause is a MIS-DECODE, not a stray volume
|
||||
|
||||
**Found 2026-08-11 by finally doing the visual**, which the notes above kept
|
||||
naming as the next step. It overturns their conclusion.
|
||||
@@ -177,9 +177,50 @@ e106_brg_01 202 verts, 202 tris 105 x 76 x 305
|
||||
```
|
||||
|
||||
**110 triangles, perfectly round axis-aligned bounds, and bigger than the ship it
|
||||
is mounted on.** That is not a turret. 🟡 It reads as a collision / trigger
|
||||
volume, and ✅ whatever it is, **the game does not draw it**: the runtime capture
|
||||
of e106 contains no `e303_wep_01` at all.
|
||||
is mounted on.**
|
||||
|
||||
### CORRECTION (same day, one iteration later): it is not a volume — it is a bad decode
|
||||
|
||||
The first reading of this was that `e303_wep_01` is a collision/trigger volume
|
||||
the assembler wrongly draws. **That is wrong, and the evidence that settles it is
|
||||
decoding the same resource from every container that holds it:**
|
||||
|
||||
```
|
||||
Stage_S01 172 verts 110 tris X[-24.5, 24.5] Y[0.0, 23.4] Z[-20.8, 20.8] ← 49 × 23 × 42, a turret
|
||||
Stage_S02 172 verts 110 tris X[-1000, 600] Y[±1050] Z[±2400] ← 1600 × 2100 × 4800
|
||||
Stage_S03… 172 verts 110 tris 49 × 23 × 42 (correct)
|
||||
Stage_S08 … 1600 × 2100 × 4800
|
||||
Stage_S26 … 1600 × 2100 × 4800
|
||||
```
|
||||
|
||||
Same resource, same vertex and triangle count, **decoding correctly in eleven
|
||||
containers and wrongly in exactly three** (`Stage_S02`, `S08`, `S26`). So:
|
||||
|
||||
- the **placement is legitimate** — `e303_wep_01` is a small shared turret,
|
||||
cross-mounted on `e101` and `e106`, and at its true size it is unremarkable;
|
||||
- the original author's explanation of the capture's silence (**vbase dedup**)
|
||||
stands, and my "dedup would show one, not zero" objection does not survive:
|
||||
with the correct decode the turret is small, ordinary geometry;
|
||||
- **the defect is in the mesh decoder**, which resolved this resource's vertex
|
||||
data differently in three containers.
|
||||
|
||||
The render and the symptom are real; the cause named in the first version of this
|
||||
entry was not.
|
||||
|
||||
### The part that matters more than this one resource
|
||||
|
||||
**The decoder can produce wrong geometry without declining.** The
|
||||
[XBG7 audit](structures/xbg7-mesh.md) counted 814 resources it *refuses* — a
|
||||
visible, honest failure. This is the other kind: `e303_wep_01` decodes "fine" in
|
||||
`Stage_S02` and is silently 100× too large. Screening for the signature (bounds
|
||||
that are exact multiples of 50 with a span over 1000) flags 22–32 models in each
|
||||
of `S02`, `S03`, `S08`, `S26`, `S27` — **but that screen also catches legitimate
|
||||
`e_rou_*` composite proxies**, so it is a candidate list, not a count of bugs.
|
||||
|
||||
**Next:** diff the anchor scan's chosen `vb0` for `e303_wep_01` between
|
||||
`Stage_S01` (correct) and `Stage_S02` (wrong) — same resource, two outcomes, so
|
||||
the divergence is directly observable — then use whatever distinguishes them to
|
||||
add a post-decode sanity check, so a silent 100× mis-decode becomes a decline.
|
||||
|
||||
### Why this was missed
|
||||
|
||||
@@ -205,6 +246,12 @@ Sweeping all 335 assembled ships for the signature *ship-scale span with under
|
||||
by capture absence, and by geometry. Some of the others may be legitimately large
|
||||
low-poly parts, and each needs the same three checks before being called a bug.
|
||||
|
||||
**Next:** decide the rule that separates drawable parts from volumes (candidates:
|
||||
the node-name suffix, a descriptor flag, or the triangle-density heuristic), then
|
||||
re-point `static_assembly_matches_runtime_capture` so it also fails on extras.
|
||||
**Still true, and independent of the correction above:**
|
||||
`static_assembly_matches_runtime_capture` walks the capture's parts and looks each
|
||||
up in the static output, so **extra static placements can never fail it**. That is
|
||||
worth fixing regardless — it is the same one-way-test shape as the earlier
|
||||
`include_external` hypothesis.
|
||||
|
||||
Also unchanged: only **two** cross-id placements exist fleet-wide (`e303_wep_01`
|
||||
on `e101` ×24 and `e106` ×36, across 335 assembled ships), so cross-id mounting is
|
||||
a narrow, real feature rather than a systemic guess.
|
||||
|
||||
Reference in New Issue
Block a user