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

VoxelForge R14 — Windows build review

Verdict: I found no likely MSVC or UHT compile blocker in the requested diff. This is a source review, not a build result. Runtime behavior has one important condition: the legacy chunk callers align with the new physical layout only at the default 8 m width.

Compile and UHT review

The diff adds no designated initializers, __int128, GNU builtins, [[likely]], or std::visit use. The std::variant code has <variant> available; Core uses C++20, and the std::llround calls have <cmath> available. The new FStrateSlot metadata is plain non-UPROPERTY data.

File:line	Issue	Surety	One-line fix
CoreNamespacePreamble.h:60, VoxelForgeCore.Build.cs:41	Toolchain check: the Core build uses C++20 and MSVC’s fp_contract pragma. Core pins C++20 and precise FP; confirm the owner’s UBT-selected MSVC version and flags.	check	Use the UE-supported VS2022 toolset and confirm /std:c++20 and /fp:precise in the build log.

Epic documents C++20 as UE’s default and minimum, and UBT’s module settings come from .Build.cs files (C++ standard, module properties). Microsoft documents that /fp:precise disables contraction by default starting with Visual Studio 2022; earlier versions could contract, while the Core preamble explicitly requests fp_contract(off) (/fp, fp_contract).

Behaviour risks

• Chunk coordinates versus micrometre bounds: VoxelStrateManager.cpp:1201 resolves physical layout width in micrometres, but GetStrateForChunk/GetStrateChunkZBounds and IsGapChunk still treat ChunkCoord.Z as a layout-chunk index. Normal world chunk coordinates use CHUNK_SIZE voxels (VoxelTypes.h:285). Those units match at the default 8 m width with 25 cm voxels; the setting also allows 0.25–64 m. At other widths, generator selection, gap detection, and transition distances can disagree with the physical slot bounds. Enforce the matching width or convert these chunk APIs using the actual streaming-chunk width.

• Stamp and cavern graph records: The Unreal adapter builds strata and passages, then finalizes its layout JSON (VoxelForgeCoreAdapter.cpp:1078, 1260); it does not call either stamp or graph resolver. The Core world is active in Unreal, but the adapter currently supplies it with no L43–L46 stamp or graph records. The current headless demo calls those resolvers directly (StreamBenchmarkHeadless.cpp:933). To get that geometry in Unreal, the adapter needs to build and serialize those records.

• Bezier FP contraction: The new Newton solve is in ShapeWorldInternal.h:6090. Core’s compile preamble disables contraction for MSVC, and World::compile runs a contraction self-check before compiling the shape. The solve itself has no graph input from the current Unreal adapter, so it should not execute in the current plugin path. Confirm the owner’s MSVC toolset; Microsoft documents version-dependent /fp:precise defaults as above.

First-build checklist

1. Confirm the UE minor version and UBT-selected VS2022/MSVC toolset.
2. Build the Win64 Development Editor target through UBT so it runs UHT and compiles both plugin modules; UBT takes module settings from .Build.cs.
3. Check the first UHT or MSVC diagnostic, then confirm the Core compile flags include C++20 and precise FP.
4. Launch the editor with the default 8 m layout and confirm Core world initialization succeeds, including its FP self-check.
5. If using a non-default layout width, resolve the chunk-coordinate mismatch before relying on streamed generator and gap behavior. Do not expect the stamp/graph demo geometry in Unreal until the adapter supplies those records.

I left the tree untouched. git status showed Standalone/Research/WorldAssemblerM3/Linux18/exports/ as pre-existing untracked content.