Fr0zka/VoxelForge
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c67b2006aac16bdecee1c7f1726df4941443bb93
VoxelForge/Standalone/Research/WorldAssemblerM3/Research36/REPORT.md
T
Fr0zkaandClaude Opus 5.5 81e2452a3d captures: readable player-view captures with a coverage gate (L69); R36 native-generator survey 
- Capture exports now cover a 90-degree player frustum (radius 3, LOD 0-8, overlap patches);
  a 17x9 ray coverage probe aborts before rendering if tiles are missing (truncated-mesh
  control: 480 uncovered samples, rejected). Clear colour is sky blue, so un-meshed space can't
  pass as dark rock. 16 views of the owner's four-strate plan.
- Explore commandlet: finite XYZ spawn override for traces (Source/, Linux-compiled).
- In-engine four-strate trace NOT obtained: the engine-generated plan fails passage validation
  at a solid centerline voxel (~(-43,-34.5,-448.5) m) while the headless owner_world.json
  plan passes. Engine and headless plans diverge.
- R36 (read-only): order TN -> VS -> FI for native migration; native FI is reachable from the
  adapter but not selected in the owner run, cause unknown.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016dhxM43dnWvUu2B5Ph1iG1
2026-10-27 04:00:49 +01:00

77 lines
15 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
## Ranked recommendation
**Keep the order TN → VS → FI.** The order is unchanged; I’ve corrected the explanation for FI and tightened the first-round gate.
| Rank | Generator | Recommendation |
|---|---|---|
| **1. TN** | Best first native-family step for caves and liminal variety. **[CODE]** A native cave graph, field evaluator and adapter recipe exist. **[ASSET]** The owner’s TN asset does not select that recipe or provide its graph. **[INFERENCE]** The parameter-to-graph work is a substantial migration, and a speed gain is unproven: the owner’s legacy TN is 0.577 s; the native cave fixture was 0.706 s. |
| **2. VS** | Strong visual payoff, but the existing native lattice is not yet a convincing shaft generator. **[CODE]** The adapter accepts `NativeLattice` for `VerticalShafts` and evaluates explicit room/tunnel graphs. **[REPORT]** The fixture looked like a corkscrew tunnel and called for an open shaft core; it took 1.694 s. This makes VS the highest geometry and gameplay risk. |
| **3. FI** | Keep last in a performance-led sequence, **not** because native FI is fixture-only. **[CODE]** Its native field, adapter planner and runtime dispatch path exist. **[REPORT]** The current owner run still reports compiled analytic FI at 1.503 s, and other FI fixtures are slower. **[INFERENCE]** It is the most mature native implementation, but its speed payoff is unclear. |
**What changed in this re-audit:** the FI adapter can auto-plan for an owner world without an imported assembly; an imported assembly must contain a matching plan for every FI stratum or validation fails. I cannot identify from the inspected code why the reported owner run still dispatches compiled analytic FI, so I withdraw the earlier suggestion that an imported override explains it. I also cannot attribute the owner’s FI time to the native mouth filter: that code runs only on the native path, while L67 reports the owner path as compiled analytic. Finally, changing TN’s field could disturb a passage landing; the first-round brief now makes the L68 route audits a promotion gate.
Labels below distinguish **[CODE]** source inspection, **[ASSET]** checked-in owner export, **[REPORT]** recorded run evidence, and **[INFERENCE]** an estimate or conclusion rather than a verified implementation fact.
## Evidence
### The native paths are reachable from the runtime adapter
**[CODE] They are not reachable only through a fixture flag.** The production route in source is:
1. `AVoxelWorld::InitializeVoxelForgeCoreWorld` calls `SerializeResolvedWorld`, parses the returned snapshot and constructs the Core `World`. [VoxelWorld.cpp:7591–7623](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelWorld.cpp:7591) [VoxelWorld.cpp:7661–7664](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelWorld.cpp:7661)
2. The Unreal adapter attaches a validated assembly. On the generated-manifest branch it calls `BuildFloatingIslandStratumPlan` for FI slots; it also writes resolved layout entries, configures each `CoreGeometry` recipe, plans passages and resolves authored room/tunnel records. [VoxelForgeCoreAdapter.cpp:1552–1664](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelForgeCoreAdapter.cpp:1552) [VoxelForgeCoreAdapter.cpp:1836–1850](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelForgeCoreAdapter.cpp:1836) [VoxelForgeCoreAdapter.cpp:1980–2000](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelForgeCoreAdapter.cpp:1980)
3. Core’s regular tile-region build passes the manifest and resolved layout to `FStandaloneShapeWorld::Build`; that build sets `bUseNativeManifestFields=true` and binds the resolved fields. This is the normal build path, separate from `bNativeOnly`, the audit mode. [VoxelForgeCore.cpp:1667–1673](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/VoxelForgeCore.cpp:1667) [ShapeWorldInternal.h:2332–2352](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:2332)
4. `DensityAt` tries native FI, then the bound native cave/surface field; `DensityDispatchPathAt` probes those same evaluators and reports the selected path. Native cave composition applies the resolved graph and shared composition. [ShapeWorldInternal.h:3068–3099](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:3068) [ShapeWorldInternal.h:3123–3140](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:3123) [ShapeWorldInternal.h:1892–1920](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:1892)
**[REPORT] Reachable does not mean active in the owner run.** L67 says the owner’s FI, TN and VS paths use the compiled analytic base evaluator. [L67 report:5](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Research/WorldAssemblerM3/Linux67/REPORT.md:5) **[ASSET]** The checked-in export selects `CoreGeometry.GeneratorRecipe=None`, so TN and VS are not opted into their graph recipes. [owner_world.json:1](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/data/owner_world.json:1) FI is different: its planner is automatic on one adapter branch, but the L67 dispatch evidence says the current run did not select it. The precise runtime reason remains unresolved.
There is one boundary to this finding: **[CODE]** the adapter has a CoreGeometry-only layout path when there are no SurfaceWorld or FI strata, but native density evaluation requires a `WorldAssembly` as well as a resolved layout. That may leave a caves-only world unable to use this path without an assembly. The owner’s four-strata world includes SurfaceWorld, so this caveat does not by itself explain its present dispatch. [VoxelForgeCoreAdapter.cpp:1602–1606](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelForgeCoreAdapter.cpp:1602) [ShapeWorldInternal.h:6570–6583](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:6570)
### Exists / missing, checked against code
| Generator | Exists: what I verified | Missing: what I verified or inferred |
|---|---|---|
| **FI** | **[CODE]** `FloatingIslandFieldV1` evaluates island plans and provides feature bounds and intervals. The Unreal adapter maps island settings and creates plans; `ShapeWorldInternal.h` binds and dispatches the field when its plan is present. [FloatingIslandsInternal.h:2286–2315](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/FloatingIslandsInternal.h:2286) [FloatingIslandsInternal.h:2492–2540](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/FloatingIslandsInternal.h:2492) [VoxelForgeCoreAdapter.cpp:857–950](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelForgeCoreAdapter.cpp:857) | **[CODE + REPORT]** No island-field algorithm port is missing. What is missing from the current owner run is successful native selection; the cause is not established. **[INFERENCE]** Likely work is path instrumentation and, only if it exposes a defect, a small adapter/runtime or verification change—not a new field family. |
| **TN** | **[CODE]** `NativeCaves` selects `Core.Caves.PrimitiveField` v1. The Unreal adapter converts authored rooms and tunnels; the Core resolver and shape evaluator resolve and compose that graph. [VoxelForgeCoreAdapter.cpp:145–158](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelForgeCoreAdapter.cpp:145) [VoxelForgeCoreAdapter.cpp:1288–1414](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelForgeCoreAdapter.cpp:1288) [ShapeWorldInternal.h:7381–7430](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:7381) | **[CODE]** The inspected adapter resolves authored Core records; it does not translate the owner’s 82-field `FStrateGenerationParams` into them. **[ASSET]** The owner recipe is None and its graph arrays are empty. A parameter compiler and explicit opt-in are therefore missing. **[INFERENCE]** Likely touch points are `VoxelStrateTypes.h`, `VoxelForgeCoreAdapter.cpp`, Core graph/schema or resolver code if needed, `ShapeWorldInternal.h` if the field needs more semantics, plus owner verification. |
| **VS** | **[CODE]** `NativeLattice` is accepted for `VerticalShafts`, and uses resolved rooms and explicit tunnel paths. **[REPORT]** A native lattice fixture proves reachability and interval checks. [VoxelForgeCoreAdapter.cpp:159–171](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelForgeCoreAdapter.cpp:159) [L58 report:9–13](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Research/WorldAssemblerM3/Linux58/REPORT.md:9) | **[CODE SURVEY + REPORT]** The inspected recipe/planner is generic lattice graph support, not a shaft-specific planner for `FVerticalShaftParams`; the fixture report says its result is not an open vertical shaft. A shaft plan/open core and safe landings remain. The claim that there is no other dedicated planner is limited to the inspected adapter/Core route; the report independently confirms the visual gap. |
**[INFERENCE] File counts from my prior answer were estimates, not counted changes.** For FI, the relevant implementation is already in `FloatingIslandsInternal.h`, `ShapeWorldInternal.h` and `VoxelForgeCoreAdapter.cpp`; first locate the selection mismatch before estimating edits. For TN, those same adapter/Core layers plus `VoxelStrateTypes.h` are the likely work area. For VS, expect those layers plus shaft-specific geometry and proof. Exact touched-file counts depend on whether existing records can represent the required parameter semantics.
### FI cost: traced paths and falsifier
There are three paths to keep separate:
- **[REPORT] Current owner path:** L67 reports `compiled-analytic/FloatingIslands`, not native FI. In `ShapeWorldInternal.h`, that means `DensityAt` falls through the native probes to `AnalyticDensityAt`; its general field path uses `EffectiveRockDistance`, the local detail pass, and shared composition. [ShapeWorldInternal.h:3068–3099](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:3068) [ShapeWorldInternal.h:5343–5422](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:5343) **I have not proved that the L55/L60 FI timings isolate this exact evaluator.**
- **[CODE] Unreal legacy generator path:** `BuildFloatingIslandStack` starts from void, adds `FIslandBlobSource`, roughness, fill and structural posts. `FIslandBlobSource` evaluates nearby hash-placed islands and contour warp. [VoxelGenerator.cpp:2630–2636](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelGenerator.cpp:2630) [VoxelDensityOpStack.cpp:2871–2935](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelDensityOpStack.cpp:2871) [VoxelDensityOpStack.cpp:9504–9533](/home/jahni/VoxelM/Plugins/VoxelForge/Source/VoxelForge/Private/VoxelDensityOpStack.cpp:9504)
- **[CODE] Native FI path:** when selected, Core samples `FloatingIslandFieldV1`; near a mouth it may add a 27-tap smoothing filter and six neighbor probes. [ShapeWorldInternal.h:6592–6608](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:6592) [ShapeWorldInternal.h:6737–6800](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:6737)
**[REPORT]** L55 attributes substantial worker work to grid and skirts: 36.414 worker-seconds of grid work and 2.787 of skirts across its 2,370-tile FI drain. These are worker-seconds for that fixture, not the current owner’s 1.503 s wall time. [L55 report:15–30](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Research/WorldAssemblerM3/Linux55/REPORT.md:15) R32’s optimistic calculation says removing all measured FI grid work from the L60 setup still leaves about 1.59 s; again, that is not the current owner path. [R32 report:41–45](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Research/WorldAssemblerM3/Research32/REPORT.md:41)
So the defensible conclusion is **native FI is not yet demonstrated to be a speed fix**. I would revise that if a paired owner benchmark held camera, tile counts and clip settings fixed, logged `DensityDispatchPathAt`, and attributed time to field sampling, grid classification, meshing/normals and skirts. If native dispatch cut the same owner cold view to about 1 s without changing passage audits, that would disprove the current caution.
### Passage and landing risk
**Yes, a TN field migration could break a contract that L66–L68 just made pass.** The shared composer consumes the generator field before applying the boundary bands and passage carves; native graph caves also skip the legacy floor-cap stage. Changing the underlying field can therefore change support near a landing even if the passage plan and composer code stay untouched. [ShapeWorldInternal.h:1892–1920](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Core/src/ShapeWorldInternal.h:1892)
L68’s three interfaces had 0 blocked, unsupported and grade failures, with wall ripple ≤3.5 cm and floor ripple ≤2.5 cm. [L68 report:11–21](/home/jahni/VoxelM/Plugins/VoxelForge/Standalone/Research/WorldAssemblerM3/Linux68/REPORT.md:11) Keeping the passage configuration fixed is necessary, but it does not prove the changed generator field preserves those results.
## First-round brief for the implementer
**Goal:** Add an explicitly opt-in native TN path for the owner’s current TN stratum. Compile its existing generation settings into a versioned native cave plan; keep legacy TN as the default until the owner plan passes all gates below. Do not change the shared passage planner or composer in this round.
**Invariants:**
- Account for every non-default owner TN setting in a field-by-field mapping. If the native graph cannot represent one, extend the recipe or reject native opt-in and leave legacy active. Do not silently drop it.
- Hold the owner’s seed, strate bounds, resolved passage configuration, passage route and shared composition code fixed.
- Keep FI and VS dispatch unchanged.
- Do not promote TN if its changed field alters a landing or route contract.
**Evidence required before enabling it on the owner asset:**
- `DensityDispatchPathAt` reports `Caves-native` throughout the TN stratum; record the resolved manifest/layout identity and graph plan used.
- Repeat the **full L68 passage audit across all three interfaces**, not just TN→VS: zero blocked/unsupported/grade failures and the same wall/floor ripple limits. Compare route and landing geometry with the fixed L68 plan.
- Recheck reachability, headroom and grade, plus interval boxes against brute-force samples; false all-air/all-solid controls must still be rejected.
- Verify deterministic hashes at W1/W8/W12 on both compilers.
- Run five interleaved cold owner whole-view repetitions with stable tile counts; target a median at or below 1.0 s and report moving p50/p95 against the legacy baseline.
Until those checks pass, native TN should remain an opt-in canary and the current owner recipe should remain on legacy dispatch.
Reference in new issue View Git Blame Copy Permalink