VoxelForge/Standalone/Research/WorldAssemblerM3/Research36/REPORT.md

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 VoxelWorld.cpp:7661–7664
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 VoxelForgeCoreAdapter.cpp:1836–1850 VoxelForgeCoreAdapter.cpp:1980–2000
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 ShapeWorldInternal.h:2332–2352
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 ShapeWorldInternal.h:3123–3140 ShapeWorldInternal.h:1892–1920

[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 [ASSET] The checked-in export selects CoreGeometry.GeneratorRecipe=None, so TN and VS are not opted into their graph recipes. 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 ShapeWorldInternal.h:6570–6583

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 FloatingIslandsInternal.h:2492–2540 VoxelForgeCoreAdapter.cpp:857–950	[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 VoxelForgeCoreAdapter.cpp:1288–1414 ShapeWorldInternal.h:7381–7430	[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 L58 report:9–13	[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 ShapeWorldInternal.h:5343–5422 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 VoxelDensityOpStack.cpp:2871–2935 VoxelDensityOpStack.cpp:9504–9533
• [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 ShapeWorldInternal.h:6737–6800

[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 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

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

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 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.