Flight integration validation

tests/flight-integration.html mounts the actual assembled shell/scenes/flight.js, using the canonical engine and portable object packages. It does not substitute a miniature flight model. The scene is frozen initially so camera, controls and POIs can be inspected without route drift. Run integration checks retains the full nine-case suite; Recheck views / POIs runs the failed-view regression subset. The high-quality profile is separate because it changes canvas resolution and advances a short guided segment.

The fixture records startup/shader/runtime errors visibly, retains framebuffer thumbnails, and renders JSON reports into the page. Integration and profiling evidence is summarized in flight-integration-summary.json. A successful automated case is not human acceptance of the visual result.

Functional scope

1. Actual exterior frame, dense forest, water, aircraft and settlement construction.
2. Paused V switching, live viewMode, pilot camera mount and cockpit projection.
3. Real cockpit master/avionics mesh picking routed through the flight scene's pointer handlers, plus actual framebuffer screen changes.
4. Keyboard gear commands, visible gear mechanism completion and linked throttle commands.
5. Every exposed POI: frame content, configured camera, terrain clearance, hidden aircraft, frozen flight and nearby woodland detail while paused.
6. A 120-second guided route: terrain containment, clearance, contact telemetry and unexpected resets.
7. Water reflection viewport restoration while rendering to a deliberately different 237 × 133 target.
8. Two flight detach/remount cycles: object scope disposal, CSM hook cleanup, removed keyboard handlers and stable retained GPU resources.
9. No recorded startup/runtime/shader errors.

The cockpit pick test projects an actual tagged control mesh into the canvas and first confirms that Engine.pick resolves the intended control at that point. It dispatches pointer events at those coordinates, exercising the real scene handlers and their callback. It does not call setControl to impersonate a physical switch click. Keyboard checks similarly exercise the scene's actual canvas handlers. Manual browser inspection supplements these event-driven cases.

Guided simulation uses the scene's own fixedUpdate for every 1/60-second step. Shared wind time advances per step, and the real scene update refreshes state/telemetry between short batches. The test does not render all 7,200 steps. That separates route correctness from frame-rate measurement. A displacement over 20 m in one step is counted as an unexpected restart, and actual contact telemetry must remain unchanged. The recorded original route maintained 255.13 m minimum terrain clearance with zero contacts and zero resets.

POI snapshots are real framebuffer samples, not a nonzero-pixel-only acceptance claim: the fixture also verifies the configured camera, live mode, body immobility, terrain clearance and nearby woodland detail. The settlement support audit separately samples the terrain beneath the actual foundation bounds and reports exposed corner gaps. Visual interpretation of placement, surfacing and anatomical quality remains separate.

Initial regressions and engine corrections

The first env6/integration4 run passed seven of nine cases. The view and POI failures had the same cause: Engine.mount used Object.assign(stage, hooks), evaluating the flight hook's viewMode getter once and storing its initial external value. The camera and cockpit controls changed correctly, but the public state stayed stale. The engine owner corrected this with descriptor-preserving hook installation in env7. The original assertions remain intact.

The first run verified master/avionics control picking with 8,586 changed framebuffer pixels, the 120-second guided route, the 237 × 133 reflection viewport, and detach/remount cleanup. Both released scenes retained the same 1 geometry and 7 textures belonging to the active postprocessing/renderer setup; old flight keyboard handlers were absent. No shader or runtime errors were recorded. Later targeted and optimization reruns are recorded separately in the JSON evidence rather than being implied by those initial results.

CPU and GPU profiling

The profiler uses the actual flight scene at high quality and a 2048 × 1152 CSS canvas. Each stationary and guided phase runs 30 warmup frames followed by 30 sampled frames. It times the real scene update, forest update, grass update, environment update, fixed step and complete engine tick. Wrappers delegate directly to the original methods and are removed after sampling. No simulation or rendering behavior is replaced.

GPU elapsed-time queries are collected only when EXT_disjoint_timer_query_webgl2 is available, completed and nondisjoint. Otherwise the report marks GPU timing unavailable. renderSubmissionMs is the remaining CPU wall time after update/fixed-step work, including possible driver waits; it is not a substitute for the measured GPU duration. Component medians are not additive sample timings.

The instance-buffer audit counts changed attribute versions and their allocated byte capacities. It establishes whether the forest marks transforms/colors/fades dirty; it is an estimate of potential upload capacity, not a bus-transfer measurement.

The initial profile found a dominant CPU forest cost despite successful stationary upload suppression:

The stationary phase marked no forest attributes dirty. Guided sampling marked 57.36 MB of aggregate buffer capacity across 30 frames. Thus the initial forest classification/list/hash work was a larger measured issue than stationary uploads or the secondary spatial-collider scan. These measurements prompted independent forest and spatial broad-phase optimizations while retaining 24,000 trees and the grove placement. The JSON report keeps the baseline and subsequent profile identities separate.

This is one Chrome setup, with varying background GPU load possible. Results do not establish performance on every device or imply visual acceptance of the landscape, cockpit, water or people. The fixture restores its original quality and canvas size after profiling and disposes its engine when its temporary tab closes.

env7 view rerun and placement audit

The targeted env7 rerun passed all three selected cases: live cockpit state/projection, all six POIs, and runtime/shader health. Beach, airfield, mountains, river, village and woodland rendered at their configured cameras with the aircraft hidden and flight frozen during inspection. Paused woodland inspection correctly submitted one nearby detailed tree. This confirms the getter and paused-LOD corrections for those views.

A separate actual-foundation audit found exposed terrain-corner gaps at 10 of 14 settlement buildings. The largest was 4.582 m at the warehouse near (610.314, 26.291, 447.701): its foundation bottom was 24.291 m while a footprint corner's terrain was 19.709 m. The audit was reported to the engine owner; it does not silently pass foundation contact as part of a generic nonblank-frame test. The external view also showed a sharp river-ribbon edge against wider reflective water, and the mountain POI was dominated by a steep gray/snow cliff. These are recorded visual observations; final visual acceptance remains with the user.

Optimized profile

The stamped v020-review1 graph was measured with the same 24,000-tree initial scene, canvas size, quality, warmup and sample counts. No shader/runtime errors occurred, and the far groves remained visibly present. Draw calls and triangle counts matched the baseline exactly.

There were 30 valid GPU samples in each phase. Neither phase marked forest attributes dirty in this initial all-far camera region; the guided phase's final frame tested two nearby spatial candidates. The rounded stationary 0.0 ms result is not a claim of literally zero computation. These results confirm removal of the dominant full-forest CPU scan and the secondary collider scan cost for this flight region. They do not establish the same timing in a dense, nearby leaf view.

Manual Chrome coordinate clicks in the assembled env7 cockpit independently verified the visible master switch: the callback/checkbox changed and the rendered screens/HUD went dark, then a second physical click restored power.

Final review2 integration result

The full v020-review2 run passed all nine cases on 2026-09-07 at 06:25:32 UTC. The POI case now also requires the settlement foundation audit to pass. All 14 named foundation meshes had zero exposed corner gap in the recorded samples, resolving the earlier 4.582 m maximum. The 120-second guided route maintained 255.133 m minimum terrain clearance, with zero contacts and zero resets. Real master/avionics picks changed 8,449 framebuffer pixels when electrical power was removed. All six POIs rendered correctly by the stated checks, including one near and 21 mid-level woodland instances while paused. Far LOD counts now describe coverage before the GPU distance mask rather than an exact visible-tree count.

The 237 × 133 offscreen viewport remained unchanged across reflection rendering. Two complete flight detach/remount cycles again returned to the same 1 geometry and 7 retained renderer/pipeline textures, with old canvas handlers removed. No startup, shader, runtime or captured console errors occurred. The single temporary flight-validation tab was closed.

The widened/raised mountain POI now provides ridge context, and the river inspection view improved. The initial external chase view still shows a distinct planar central river strip against more reflective flanks near the outlet. This remaining visual observation is recorded explicitly; the numerical passes do not establish human visual acceptance or photorealism. The optimized performance profile was measured on v020-review1; later shoreline geometry changed modestly in review2, so the earlier exact draw/triangle counts are not asserted for review2.

Download the original Markdown