I’ll read the committed round-three report first, then establish a fresh cold baseline with stage, LOD, worker, and idle-time breakdowns before changing the standalone. I’ll preserve the fixed visual and determinism checks throughout.
I’m continuing from the measured round-three state. First I’ll read its report, then I’ll run fresh 8- and 16-worker cold baselines and inspect which stages dominate before selecting any optimization.
The committed report confirms the last source state, and the prior shape/quality audits are available. The cold whole-view benchmark already reports aggregate shape stages and worker-time per LOD, but not per-LOD wall intervals or neighborhood readiness; I’m recording those gaps while I take the fresh baseline.
The fresh baseline reproduces the gap: at 16 workers the compiler stage is 0.783 s and uncached meshing is 0.827 s; at 8 workers those are 1.050 s and 1.078 s. In the mesh work, LOD6 accounts for about 6.5 worker-seconds at 8 workers and 9.7 at 16, so the far shell is the main parallel workload; the sign/detail compiler’s surface band is the largest single compile stage. I’m tracing both now and adding the missing wall-time slices before changing them.
The profile shows two useful implementation facts: the sign pass already does interval solving and packed words, and tile meshing is already independent per worker with thread-local density scratch. The missing profiler slices are now instrumented, including per-LOD completion and worker busy time. I’m rebuilding this measurement-only change, then I’ll use those timings to decide whether page batching or evaluator work is the right target.
The finer profile changes the optimization choice: at 16 workers, the detail pass is 0.395 s wall but has about 6.2 worker-seconds of work, while far LOD6 costs about 10 worker-seconds. The hot field path does three spatial hash lookups per sample (cave, overlay, critical-air) against the same bin. I’m preserving a pre-change density hash now, then I’ll combine those lookups into one ordered primitive scan and verify bitwise equality.
The density hashes are identical for the full clipmap and every LOD before and after merging the field lookups. The no-hash run improved full-stream worker work from 13.27 to 11.65 s at 16 workers, with LOD6 dropping from 9.73 to 8.60 s. I’m testing a second, exact optimization: build the vertical candidate mask directly, then merge the two horizontal masks in parallel with atomic bit-ORs. This targets the 40 ms serial mask pass without changing candidate membership.
The parallel mask merge passes the exact per-LOD density hashes and cuts the interval/sign stage by roughly 14 ms on the 16-worker run. I’ve also found another cheap reuse opportunity in the far evaluator: adjacent samples revisit the same spatial bin, so I’m adding a generation-checked per-worker last-bin pointer. It changes only lookup, not bin contents or density math.
The profile still points to two expensive regions: fine detail evaluation in the shape build, and LOD6 meshing. I’m checking the experimental bin-cache edit now; its runs kept the hash but showed no reliable speedup, so I’ll remove it unless the source check says it was already reverted, then continue with neighborhood and edit measurements.
I’ve added two measurement hooks before tuning further: cold readiness for the 3×3×3 level-zero player neighborhood, and a single queued edit transaction that combines sphere, rounded-box, and capsule brushes, then remeshes only intersecting visible tiles at each LOD. The edit benchmark uses no mesh cache; the standalone still cannot cook collision, so I’ll report mesh readiness separately from actual collision readiness. I’m building this instrumentation now.
The edit transaction now completes its 27 affected LOD0 tiles in 19 ms at 8 workers and 11 ms at 16, with zero cache hits. In this view no coarser tile intersects the brush bounds; the report will list only the levels actually affected. The current build succeeded with the known `vswhere` setup message and six unrelated narrowing warnings. Next I’m measuring neighborhood readiness and the final cold 8/16 worker timings.
Cold results are now in: the full-detail region plus its 27-tile neighborhood is 0.714 s at 8 workers and 0.595 s at 16, with mesh-only neighborhood readiness at 17/19 ms. The whole view is still 1.881/1.527 s because the detailed field build and the 6,498-tile mesh run sequentially; the coarsest LOD alone consumes 0.957/0.753 s. I’m checking whether a low-risk overlap or meshing change can close that gap without changing the field.
The far-parent timing includes a redundant rebuild of the three axis-line indices after interval compilation is already finished. Those indices only serve the interval solver; far-field queries use spatial bins. I’m removing that post-solver rebuild and will reject it if exact mesh hashes or route/quality checks change. This is a measured 100+ ms target and avoids a field approximation.
The parallel far-bin assembly preserved every mesh hash, but it did not lower the 107–112 ms bin stage or whole-view time; its extra per-worker maps are not justified. I’m dropping that trial and trying only capacity reservation on the existing deterministic builder. The coarse LOD remains the dominant mesh stage, so I’ll keep the failed speed hypothesis and its measurements in the report.
The capacity reservation is a useful low-risk win: the far spatial-bin stage fell from about 112 ms to 96 ms, with 328,944 bins and 1.58 million references. The exact field and per-LOD mesh hashes stayed the same in the axis-skip trial; I’m doing the final hash sweep on this reserved-builder source now, followed by the route, stair, sheet, and fixed-view checks.
The final-source audits pass: all 5,642 route samples remain open; chamber/tunnel/passage grid-stair indices are 0.003/0.028/0.205 against 0.400; the whole-view level-zero mesh has 0 thin sheets and 0 isolated small components. Three small components touch tile boundaries, which the per-tile audit cannot classify as detached. I’m refreshing the six fixed captures now, then I’ll review them alongside the owner views.
The exact final rebuild succeeded after I replaced the edit probe’s square roots with explicit SSE instructions, keeping that added field operation deterministic under the stated constraints. Hashes still match. I’m refreshing the no-hash whole-view timings and image captures from that exact executable before I close out the report.
One refreshed passage PNG has a different file hash from its earlier capture, although it looks identical at display scale. I’m checking decoded pixels before calling it unchanged; I’ll record the exact result rather than treating a file-hash mismatch as harmless metadata.
The final exact-source runs confirm the same limiting pattern: LOD6 costs about 0.99 s at 8 workers and 0.74 s at 16; shape compilation adds another 0.88/0.74 s before it can begin. I’m looking at the mesher’s sampling and allocation path once more to see whether there is a field-preserving structural cut larger than the bin reservation. If there isn’t, the report will call out the remaining gap plainly.
The mesher already reuses per-thread density grids and avoids a shared vertex append lock, so there is no cheap mesher-side switch left to try. One larger safe-to-test option is overlapping far LOD work with fine field compilation: start only coarse tiles whose sample bounds cannot touch the unfinished fine lattice, then queue the near levels once that lattice is ready. I’m implementing this as an opt-in cold benchmark path and will keep it only if hashes, routes, and images stay exact.
I’m checking the overlap experiment’s working-tree state first. If the partial patch didn’t land cleanly, I’ll apply it in small pieces, then build and compare hashes before deciding whether it stays.
The overlap path is now wired as an opt-in benchmark: it splits the requested worker pool between far tiles and the shape compiler, then adds the remaining workers once compilation finishes. First I’m building the reordered shape stage and running the existing hash audit; the far parents are added before interval compilation now, so exact equality is the first gate.
The first exact hash run caught a real flaw in the moved stage: the far build changed the spatial bin size used by fine-detail sampling, which altered LOD0/1 meshes. I’m separating the far query index from the fine compiler’s bins now, so far tiles can start early while detail compilation keeps its original sampling index and results. I won’t keep the reorder unless the old hashes return.
I’ve removed the overlap prototype after it failed the exact output check; I’m restoring the prior build and stream path now. The useful result from the failed prototype is that far LOD2–6 hashes stayed stable while LOD0/1 changed, so that ordering isn’t safe without a deeper split of the local and far field data.
The overlap idea is shelved. I’m doing the last audit against the rebuilt source now: fresh worker-count hashes and cold 8/16 timings, then I’ll align the report to those outputs and record the rejected ordering experiment. The old saved hash set does not match the rebuilt binary, so I’m treating that mismatch as a failed comparison and checking whether the rebuilt result is internally deterministic.
The rebuilt binary is stable across 1, 8, and 16 workers, but it produces a different LOD0/1 density hash from the saved “final exact” run; LOD2–6 still match. I’m treating that as an unresolved output-baseline discrepancy, not claiming the prior hashes passed. I’m gathering the remaining cold neighborhood and edit timings against this rebuilt binary so the report separates verified results from the old record.
I found the fixed camera table in the round-two report, so I can refresh the same six views instead of relying on the older PNGs. I’m capturing chamber, tunnel, passage, far, floor close-up, and bend from the rebuilt binary now; this will show whether the LOD0/1 hash difference is visible.
The six refreshed fixed-view screenshots confirm the rebuild looks unchanged: five are byte-identical to the saved captures; the passage differs at only four pixels by one channel value. I’m rerunning the fixed-view stair/detail audits and the thin-sheet shard audit on this binary before I finalize the report.
The current rebuild’s hashes match the earlier far-first prototype; the mismatch is with the older saved hash record, not between the two stage orders. That gives me a safe test target: I’m re-enabling the prestart only behind an explicit benchmark flag, then I’ll require exact matches against the rebuilt baseline and keep it only if it reduces whole-view wall time.
The measured overlap run is not a win: at 8 workers it reaches 1.831 s versus 1.888 s sequential, but at 16 workers it regresses to 1.553 s versus 1.497 s. The split doubles contention during the detail band, stretching its wall time to 0.802 s at 16. I’m removing this path; it does not justify its complexity or meet the one-second target.
I’m removing the measured-but-unhelpful overlap prototype, then I’ll rebuild the exact clean source and refresh its hash and report evidence. The no-overlap profile still misses the whole-view target, so I’ll keep the report explicit about that gap and the unexplained difference from the older saved hashes.
The clean rebuild command hit a PowerShell logging-path error because `Build.ps1` temporarily changes directories; the compiler may still be running. I’m checking that process before retrying with an absolute log path so I don’t overlap two builds.
The overlap code is gone and the `/MP16` rebuild succeeded. I’m now verifying determinism against that rebuilt executable at 1, 8, and 16 workers, including a second 16-worker run; then I’ll update the report with the rejected overlap timings and the final build record.
The rebuilt measurements put the remaining cost in two places: at 16 workers the shape build is about 0.73 s, while LOD6 meshing is about 0.74 s; LOD6 alone accounts for most mesh time. The early-stream experiment overlapped work before the far-field shape existed, so I’m treating it as invalid for correctness and retaining only its timing as a rejected prototype. I’m checking the mesher’s tile workload and current field loops before choosing the next change.
The source already uses cell pruning and thread-local output buffers, but every emitted triangle still performs repeated position-key hash lookups to deduplicate shared grid-edge vertices. VTK’s Flying Edges design avoids that pattern with edge-indexed vertices and preallocated passes. I’m testing a smaller compatible step: cache each lattice edge’s vertex index per worker, while retaining the old position-hash fallback for degenerate crossings. It should preserve vertex order and geometry while cutting repeated map probes.
The edge cache builds successfully. It preserves the old coordinate hash as a fallback, so its correctness path only changes repeated references to the same lattice edge. I’m measuring the whole view at both worker counts first; if the output checks pass and the gain is stable, I’ll keep it, otherwise I’ll revert it.
The exact-preserving version keeps the vertex and triangle counts unchanged, but it does not give a stable whole-view win: 8 workers moved from 1.996 s combined to 1.994 s, while 16 moved from 1.471 s to 1.484 s. I’m removing it; the first version’s slightly lower vertex count was also a real geometry difference, so it is rejected. I’ll document both candidate results and leave only measured, correct code in the source.
The final rebuilt owner scans are taking longer than the earlier close-view checks: the far LOD6 scan is still processing its 4,770-tile sample set. It is the only heavy process running; the 8-worker close scans completed normally. I’m letting this single scan finish before touching the final report.
The fresh owner scans reproduce the round‑two sign percentages and sampled surface distances to the displayed precision; the saved scalar hashes differ, but the measured signs and geometry-distance metrics do not. The far scan passed with zero field-sample mismatches. I’ve restored and rebuilt the baseline mesher after rejecting the edge-cache prototype; I’m doing the final hash verification on that exact executable now.
The new process clock shows the real cold command-line wall time is higher than “shape build + stream” alone: **2.113 s at 8 workers and 1.682 s at 16** from process start through the farthest LOD. The one-second whole-view target therefore remains unmet even before GPU upload. I’m measuring the same process-start boundary for the full-detail workload too.
The improved crater benchmark now straddles the LOD0/LOD1 seam: one transaction remeshed 12 LOD0 and 2 LOD1 tiles, with zero cache hits. It took 14 ms edit-to-ready at 8 workers and 27 ms at 16. I’m rebuilding and hashing this exact final source so the report’s edit case and determinism evidence refer to the same tree.
The profile confirms why the overlap and small cache tweaks weren’t enough. At 16 workers, shape compilation is 0.727 s; the stream is 0.744 s, with LOD6 consuming 8.6 of 11.7 worker-seconds and about 79 MiB of mesh output. The sampled mesher breakdown puts density-grid evaluation and triangle/vertex emission at similar cost. I’m updating the report to distinguish composite stage time from true process-start wall time and to include the correct cross-LOD edit case.
The final status check caught only a whitespace difference in the rejected mesher experiment; I’ve restored the source exactly. I’m doing one last `/MP16` rebuild of that restored tree, then I’ll verify the report links and leave the workspace uncommitted.
I’ll pick up at the mesh-hash instrumentation, first checking the current report and source state, then I’ll finish the hash output and rebuild before running the exact-source determinism set.
The current report’s “mesh” hashes are actually density-only hashes. I’ve added a separate deterministic hash over each emitted CPU tile’s vertex positions, normals, and indices; I’m compiling that diagnostic now, then I’ll regenerate 1/8/16-worker hashes from the rebuilt executable.
The rebuilt hashes now cover both the scalar samples and actual CPU mesh arrays; all four cold runs match across 1, 8, and 16 workers with zero cache hits. The latest profile still points at two large costs: LOD6 meshing and serial far-parent construction. I’m looking for a result-preserving optimization in those measured hotspots before settling the report.
The far spatial index creates about 329,000 tiny per-bin vectors. They hold an average of roughly five primitive IDs, so most pay for a separate heap allocation even though the lists are very small. I’m testing a four-ID inline bin list that keeps the same primitive order and spills only larger bins to a vector; it avoids the extra count/fill pass and should preserve field results exactly.
The inline bins passed the first exact checks: the whole density and mesh hashes are unchanged, all 5,642 route samples remain open, and far-bin construction fell from 97 ms to 53 ms in the 16-worker profile. I’ll measure the no-hash cold path at both worker counts now; the hash diagnostic itself adds enough work that I won’t use its wall time as the speed result.
The first inline-list version cut bin-build time, but it enlarged every hash-map node and appears to have offset some of the gain during field queries. I’m keeping the four-item inline layout while packing it into the same 24-byte footprint as `std::vector`; this tests whether allocation savings survive without the larger lookup structure.
The compact four-item version compiles and preserves the measured shape checks. One 16-worker no-hash run is at 0.679 s shape compile + 0.761 s meshing, versus the prior 0.727 + 0.744 s; I’m separating run variance from lookup cost and testing whether the hash-map node layout is now the limiting factor.
I’ve replaced the far/local primitive lookup table with a flat open-addressed index while keeping each bin’s primitive IDs in insertion order. This follows the cache-locality rationale from Abseil’s Swiss-table design notes and Meta’s F14 write-up; I’m treating it strictly as a benchmarked experiment because open addressing can lose if probe chains outweigh the locality benefit.
The flat table built and preserved the route checks, but the no-hash whole stream rose to 0.804 s from about 0.744 s while the shape build fell. That makes the saved 12 ms in shape work a net loss; I’m rejecting that table and retaining the compact inline bin lists on the existing hash map, whose combined stage result was better.
The final no-hash whole-view run is 0.828 s shape + 0.986 s streaming at 8 workers, and 0.679 + 0.758 s at 16. Full detail is also freshly remeasured below one second of process wall at 16 workers (0.889 s); I’m refreshing the one-transaction cross-LOD crater timing next, then I’ll rerun the complete final determinism matrix.
The crater transaction still reaches every intersecting tile in one batch: 14 affected tiles, zero cache hits, and 20 ms / 27 ms request-to-ready at 8 / 16 workers. The CPU neighborhood meshes are ready in 18 / 19 ms after streaming starts; this standalone runner cannot measure the plugin’s collision cook. I’m now hashing density and mesh outputs on the final compact-bin build.
The final owner scans on this source reproduce the prior lattice and surface-distance results exactly: chamber 5.895% sign disagreement / 1.0826 m mean, passage 3.304% / 1.0292 m, and far 9.041% / 2.1588 m. I’m trying one small mesher allocation change next: reserve the existing per-worker vertex map from the tile’s cell count to avoid repeated growth while keeping the same key and emission order.
The vertex-map reserve is result-preserving and slightly reduced the 32-tile LOD6 sample profile: 33.513 → 33.145 ms, including stream building 13.177 → 12.904 ms. That’s a small signal, so I’m checking cold whole-view timings before deciding whether to keep it.
The vertex-map reserve was retained: its 32-tile attribution improved slightly, and the no-hash 16-worker whole view stayed at 0.756 s for streaming while the crater batch measured 15 / 18 ms end-to-end at 8 / 16 workers. I’m running the final four hash jobs now so the determinism evidence matches the exact source that will be reported.
The final hash matrix passes: density and CPU mesh hashes match across 1, 8, and 16 workers, including both 16-worker repeats; every run reports zero cache hits and all 5,642 route samples open. I’m saving runner wall-time records for the report, then I’ll update the stage table and list the experiments that helped or were rejected.
One hash scope detail surfaced before the report: the current mesh digest covers positions, normals, and indices, but omits UVs, colors, and surface-group counts. I’m extending it to cover every array emitted by `FVoxelMeshData`; then the final determinism claim will cover the complete uncached mesh payload, not only geometry.
I’ll reconcile the report with the final measured logs, check the working tree and remaining processes, then summarize the target miss and verified results. I’ll keep all edits and artifacts inside `Standalone\` and won’t commit or stash.
The final logs confirm the main cost is split between compiling the field (0.672 s) and meshing LOD6 (0.778 s at 16 workers); both pools are nearly saturated. The compact bin change improved construction, but it cannot close the remaining 0.454 s gap by itself. I’m checking the field and mesher hot paths now for a larger, hash-preserving reduction before I finalize the report.
A promising exact-output optimization surfaced in the field compiler: detail candidates are visited in ascending Z on each X/Y line, while the relief uses three interpolated value-noise octaves. Those calls currently rehash the same X/Y corners many times. I’m adding a line-local cache that reuses those hashes across Z samples; it keeps the same interpolation order and does not persist across cold runs.
The code compiled cleanly. My first hash-run launch passed the argument list as one comma-joined string, so the executable treated it as a data path and exited before benchmarking. I’ve preserved that failed run and am correcting the runner invocation before measuring.
The cached relief preserved every density and mesh hash at 16 workers and cut the measured detail-band stage from about 375 ms to 298 ms. The remaining stream path also re-detects integer lattice coordinates with three rounding operations per sample. Since the mesher already knows those coordinates are integral, I’m adding a lattice-specific entry point that uses the same packed field values directly, then I’ll verify exact hashes before keeping it.
The lattice-specific dispatch also preserves all hashes and improves the 16-worker full-detail stream from 0.183 s to 0.129–0.141 s in hash runs. I also tested a per-tile snapshot to bypass atomic shape-pointer loads; its stream timing did not beat the prior run, so I’m removing that complexity and keeping the two changes with measured gains.
I found a larger redundant cost in the analytic mesh path: every non-packed density query evaluates `EffectiveRockDistance` once to get its sign, then evaluates the same field again to get its magnitude. Coarse tiles make many such queries. I’m fusing those evaluations into one while retaining the existing sign clamp and edit-brush order; exact mesh hashes will decide whether it stays.
The fused evaluation kept the 16-worker density and mesh hashes unchanged and cut the hash-run stream stage from 0.698 s to 0.624 s. I found another avoidable cost on far tiles: they need the final rock distance and critical-air override, but the current evaluator also computes surface-family and detail-influence metadata that those points never use. I’m testing a reduced analytic path with the same cave/overlay distance order.
I’m testing a larger far-field representation change: the parent network currently approximates each long connector with many overlapping ellipsoid segments, producing roughly 181,000 primitives and 1.43 million bin references. The code already has an exact swept capsule primitive, so I’m trying one constant-radius capsule per distant connector. That should remove construction seams and bin work; I’ll keep it only if route, surface checks, and the far capture remain coherent.
The capsule trial passed routes and preserved LOD0/1 hashes. It cut far-parent construction from about 83 ms to 8 ms; bin construction stayed near 46 ms, while far meshing rose slightly because capsule distance evaluation recomputes its axis each sample. I’m caching each capsule’s immutable axis data now to reduce that per-sample cost, then I’ll judge the far geometry and compare the hashes across worker counts.
The direct far capsules cut parent generation by roughly 75 ms and reduce the far network from 181,836 primitives to 16,491. The two 16-worker hash runs and the 1- and 8-worker runs match exactly; LOD0/1 are unchanged and all 5,642 route samples stay open. I’m checking intermediate worker counts and the refreshed far/mesh audits before choosing the final report numbers.
The final surface checks pass: the grid-stair, detail-family, floor-join, tunnel-join and thin-sheet audits are all green; the full stream reports zero thin sheets and zero isolated small components in view. I’ve started a fresh 8-worker LOD6 owner scan because the distant connector shape changed; the closer views retain their prior hashes.
I’ll continue from the saved candidate: first verify the source and report state, then run the remaining read-only checks and update the report with the final measurements and any unresolved limits. I’ll keep all edits and artifacts under `Standalone\` and won’t touch commits or external viewers.
The existing report predates the latest optimizations, so its headline figures and hashes are stale. The latest profile points to two remaining costs—surface detail evaluation and the 4,770-tile far LOD stream—so I’m checking their measurements and the exact current source before deciding on one more targeted optimization.
The coarse LOD stream is the largest measured stage: LOD6 alone samples 32.7 million density points and emits 81 MiB of CPU mesh data, while the workers stay 96.6% busy. I found a safe standalone-only cost to test: the mesher builds UV and biome-color arrays that the CPU stream immediately discards. I’ll add a switch that skips only those unused arrays, leaving density, positions, normals, triangle classification, and skirts intact, then compare hashes and cold timings.
The first safe fast path produced 6498/6498 tiles in 0.384 s at 16 workers (down from 0.572 s); hashes aren’t checked yet, but vertex/index counts match. It still misses the cold process target. The CPU viewer also drops the ceiling/ground material groups, so I’m testing a second standalone-only skip: bypass that per-vertex classification and keep the same triangles in one index group. This changes index ordering, but should leave the rendered geometry unchanged; I’ll verify both images and deterministic hashes.
The material grouping skip reduced full-view meshing again: 0.315 s, with a repeat at 0.285 s; the best cold process wall is 0.958 s. The one-second result is too close to trust from a single sample. I found one more low-risk build cost: the spatial hash reserves buckets from primitive count, while measured far bins number about 23 per primitive. I’m adjusting reserve sizing to the observed bin-to-primitive ratio and will keep it only if repeat timings improve with unchanged hashes.

Takeover continuation — half-load rule restored
- Read the predecessor progress, report, local logs, and commit summary before continuing. All builds and heavy runs in this continuation used BelowNormal priority and affinity 0xFF00; the final build is /MP8. Updated the Build.ps1 comment to reflect the cap.
- Read the actual plugin mesh/material path without editing it: UV0 and vertex colors are enabled and copied; FColor carries biome/slope/border channels; polygroup 0 is ground and 1 is the sky-cap ceiling material, which does not cast shadows. Full payload remains the headline. Standalone UVs are stored as FVector2f to match stream precision; the measured staging saving had no stable time gain. The dense per-tile group cache was reverted after no stream improvement.
- Hash-checked each skip path over full detail, full clipmap, and LOD0–6. Density and canonical oriented topology match the full payload in 9/9 outputs for UV/color skip, group skip, and both. Group skip changes serialized mesh order in 3/9, as expected; full payload hashes differ when attributes are omitted. Combined no-hash skips took 1.533/1.536 s process wall, recorded only as a viewer-side number.
- Compared the far-bin 24x reserve to the old 2x estimate on otherwise-current source. W8 density, geometry, complete payload, and oriented topology hashes all match in all nine outputs. Far-bin construction averaged 47.9 ms at 2x and 41.9 ms at 24x; whole stream stayed about 1.113 s. Kept this as a small stage allocation win. Restored 24x and rebuilt final source.
- Final restored W1/W8 matrices match for all four hashes in all nine outputs; 5,642/5,642 route samples remain open and cache hits are zero. Final no-hash full-payload W8 process walls were 2.174 and 2.135 s (mean 2.155); shape stage mean 0.832 s, stream mean 1.113 s, full payload allocation 235.49 MiB. LOD6 remains the main stream cost at 1.109 s.
- Final half-load chamber/tunnel/passage audits pass (grid-stair 0.003/0.028/0.205), whole LOD0 shard audit passes with zero sheets and zero isolated components, and the 10 m three-brush crater is one transaction remeshing 12 LOD0 + 2 LOD1 tiles in 17 ms to ready.
- Regenerated six fixed captures under the cap; five are byte-identical to the preceding rebuilt captures. Passage differs in 662/1,024,000 pixels (max channel delta 97) but looks unchanged side by side; owner/world visual differences remain, documented in REPORT.md.
- Failed invocations preserved in REPORT.md: one wrong executable name stopped before starting a child, and the first capture batch split --camera/--capture values and exited 2 before opening a viewer. Corrected runs all passed. One earlier dense-cache build had CellsPerAxis out of scope; corrected build succeeded before that prototype was reverted. The final build succeeds with recurring vswhere diagnostic and six existing C4838 warnings.
- Updated REPORT.md with the full-payload stage table, per-LOD data, complete hashes, skip and reserve A/B, route/edit/audit results, six captures, and failure log. No changes outside Standalone; no commit, push, or stash.
Round 5 continuation — far-field LOD8 trial (2026-10-04)
- Read REPORT.md and predecessor progress first. Built a temporary LOD8-default candidate, measured it, then restored and rebuilt the source's exported LOD6 default. No tracked source diff remains; all build outputs, captures, logs and report updates are under Standalone.
- Cold W8 full-payload LOD8 process walls were 1.406/1.289 s (mean 1.348); shape stage 698/703 ms; full-detail stream 215/212 ms; full clipmap 434/431 ms. It generated 2,226 tiles, used 92.61 MiB payload allocation and had zero cache hits. LOD6–8 used 3.415 M density samples versus LOD6's 32.717 M.
- Restored-default LOD6 W8 full-payload process walls were 1.809/1.664 s (mean 1.737); shape stage 706/696 ms; full-detail stream 247/226 ms; full clipmap 850/861 ms. It generated 6,498 tiles, used 235.29 MiB and had zero cache hits. Thus LOD8 crosses 1.5 s, but LOD6 misses it by 0.237 s.
- Candidate LOD8 and final-default LOD6 both match their W1/W8 full-payload hashes (44/44 and 36/36 respectively), retain 5,642/5,642 open route samples and pass the requested W8 detailed shape/look audit. LOD0 shard audit passes with no isolated-in-view small components; it is not a far-shell proof.
- Six fixed after-clipmap captures and three additional center-camera far headings are pixel-identical between LOD6 and LOD8. The remote X=500 m yaw-90 comparison changes 28,982/1,024,000 pixels (max channel delta 38); yaw 180 is identical and yaw 270 changes 143 pixels (max 1). LOD7's yaw-90 capture is identical to LOD8. Since the per-shell/per-connector coarse-sampling survival audit is not implemented, retained default LOD6 and left LOD8 opt-in; the far-field goal is not yet complete.
- Both builds succeeded at /MP8 or less and all child runs used BelowNormal/0xFF00. Build logs retain the non-fatal vswhere diagnostic and six existing C4838 warnings. Two initial hash wrapper invocations failed before child launch due to PowerShell array syntax; corrected W1/W8 runs exited 0. An initial hash parser counted 9 fields because it took one match per line; corrected all-match parser passed. No build/run OOM or 0xC0000142; never closed a viewer.
- Updated REPORT.md with timings, hash checks, audit scope, captures, remote discrepancy, machine setup and failed invocations. No commit, push, or stash.
