Full-bake gate baked all 729,888 EnvCells as separate fileId-keyed blobs = 865 GB pak in 52 min, 97 pct near-duplicate cell geometry. The prior 'v1-acceptable duplication' call was wrong by ~100x. Bake-time dedup (compute geomId, extract each unique geometry once, alias all sharing cell-fileIds to one blob offset) is now a v1 requirement; needs no format or reader change and collapses size AND bake time together. MP1b not shipped until the dedup slice lands.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
MP1b review finding, verified against EnvCellRenderer.GetEnvCellGeomId:
runtime dedups interior geometry under a 64-bit content hash (bit 33),
not the cell fileId the pak keys by. MP1c maps at the RegisterCell seam
(read pak[cellFileId], register under geomId, dedup post-load as today);
duplicate blob content on disk is v1-acceptable. GeomId-keyed baking is
not viable in format v1 (hash exceeds PakKey's 56 usable bits).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Normative v1 format (ACPK header with dat-iteration stamps, sorted
24-byte TOC entries with crc32, 64-byte-aligned uncompressed blobs,
deterministic ObjectMeshData serialization), the bake CLI that drives
MP1a MeshExtractor in parallel, the mmap zero-copy PakReader, and a
dat-gated live-vs-pak equivalence suite. Scope-fenced to the
ObjectMeshData asset classes (the decode-storm content from the MP0
baseline); terrain/BSP/scenery/degrade blobs are later slices. Also
amends the spec: PakReader lives in AcDream.Content (Content->Core
direction from MP1a makes a Core home circular).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
MP1a ground truth: the runtime atlas consumes decoded RGBA8 via
TextureBatchData, so baking to BC7/BC1 (lossy) would change delivered
pixels and contradict the phase's own byte-identical conformance gate.
V1 stores RGBA8 exactly as the runtime produces; BC becomes an explicit
post-conformance option with its own visual gate. Mip chains stay
runtime-generated in v1.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Full-route capture (Holtburg -> dungeon 0x0007 -> town 0xCE94 -> dungeon
-> Holtburg, 4 teleports) plus the supplemental town run. Verdict: the
render-side-CPU split is confirmed (GPU <= ~2.7ms, upd/upl/imgui ~= 0),
steady medians beat the spec assumption (worst town p50 3.6ms), and the
smoothness gap is GC: 1.5-3 MB allocated per frame drives gen2
collections 1-2/s and every town p99/max violation, while dungeon
windows (zero gen1/gen2) are spike-free at ~2000 fps. Teleport hitch
quantified at 211ms worst frame / 75.7MB single-frame allocation.
Gate decision: PROCEED to MP1 unchanged, with one recorded amendment -
a bounded post-MP1 allocation-triage session for churn sites outside
the MP3 rewrite surface. Fort Tethana axiom view still to be
re-measured at the MP2/MP3 gates.
MP0 complete: profiler shipped (7d74c68c..4b44a152) + baseline + gate.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Umbrella design for the user-commissioned performance side track:
MP0 honest frame profiler -> MP1 baked asset pak (acdream-bake CLI,
mmap zero-copy reader) -> MP2 retail distance-degrade (hide-only cut)
-> MP3 Arch ECS render world + delta submission -> MP4 zero-alloc +
flat physics data (queued behind M1.5 #137) -> MP5 jobs (stretch,
evidence-gated).
Decisions recorded: C# not Rust (bottleneck is architectural, not
language); ECS scoped to the render world only (simulation keeps its
retail-mirroring OO structure); Arch framework per user choice; bake
as CLI now, client auto-detect later; smoothness gated before the
300+ FPS throughput target. Every phase has a numeric + visual gate;
legacy paths delete at each gate (no lingering dual pipelines).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
