Skip to main content

Introduce the Terrain Pipeline

Overview​

User capability

Establish heightmap terrain and aligned Rapier collision

User

The AeroSim delivery team

What the user can do

Establish heightmap terrain and aligned Rapier collision

Why the user benefits

The capability becomes an explicit, testable project boundary.

User need

The delivery team needs the AeroSim solution to establish heightmap terrain and aligned Rapier collision.

In scope

Establish heightmap terrain and aligned Rapier collision

Tasks​

AEROSIM-TS-31Planning status: Done

Define the normalized height-data contract

Terrain rendering and collision consume one validated normalized height-data representation with explicit dimensions, scale, origin, sampling, and coordinate conventions.

  • ComponentWeb Application / Deterministic flight runtime — Shared flight-core — normalized terrain data contract
  • Depends onAEROSIM-TS-27, AEROSIM-TS-30
  • RequirementsFR-0054, NFR-0007
AEROSIM-TS-32Planning status: Done

Generate rendered terrain from normalized heights

The R3F flight scene generates its terrain geometry and elevation sampling from the normalized height-data contract.

  • ComponentWeb Application — R3F terrain renderer
  • Depends onAEROSIM-TS-31
  • RequirementsFR-0054, NFR-0007
AEROSIM-TS-33Planning status: Done

Generate Rapier terrain collision from normalized heights

The physics runtime generates the terrain collider from the same normalized height data used by the renderer.

  • ComponentWeb Application — Rapier terrain collider
  • Depends onAEROSIM-TS-32
  • RequirementsFR-0054, NFR-0007
AEROSIM-TS-34Planning status: Done

Verify rendered and collision elevation parity

Representative probes demonstrate that rendered and collision elevations remain within the documented tolerance across the terrain fixture.

  • ComponentWeb Application and shared flight-core — terrain parity tests
  • Depends onAEROSIM-TS-33
  • RequirementsFR-0054, NFR-0007
AEROSIM-TS-152Planning status: Done

Author one world-space and Coastal compositing contract

Terrain presentation, spawn, collision, aircraft presentation, and camera coordinates share one authored world-space contract, and Coastal Range renders correct water depth/transparency and visible content attribution.

AEROSIM-TS-160Planning status: Done

Repair production world identity and terrain composition

Training Airfield, Coastal Range, and Mountain Valley each render their selected identity with continuous usable terrain and no voids, black wedges, or mismatched world content.

  • ComponentWeb Application — production world identity and terrain composition
  • Depends onAEROSIM-TS-152
  • RequirementsFR-0054
AEROSIM-TS-172Planning status: To Be Released

Correct Training Airfield UAT imagery seams and atmospheric continuity

The existing Training Airfield has continuous imagery and consistent horizon blending without changing its approved world, scale or design.

  • ComponentTraining Airfield terrain rendering and atmosphere
  • Depends onAEROSIM-TS-160
  • RequirementsFR-0054

Acceptance outcomes​

  1. 01

    Visual terrain and Rapier collision are generated from the same normalized height data.

  2. 02

    Representative probes keep rendered elevation and collision elevation within the defined tolerance.

Functional requirements and measurable criteria​

FR-0054

Introduce the Terrain Pipeline

The system shall establish heightmap terrain and aligned Rapier collision.

Acceptance 01

GivenAEROSIM-FT-47 is exercised within its governed scope under supported conditions

Whenthe primary capability path is completed

ThenVisual terrain and Rapier collision are generated from the same normalized height data

EvidenceFuture reviewed automated and browser evidence must verify this exact outcome against the current requirement.

Acceptance 02

GivenAEROSIM-FT-47 is exercised within its governed scope under supported conditions

Whenthe continuation or repeat path is completed

ThenRepresentative probes keep rendered elevation and collision elevation within the defined tolerance

EvidenceFuture reviewed automated and browser evidence must verify this exact outcome against the current requirement.

Non-functional requirements

Risks​

  • Risk

    Partial introduction could leave an ungoverned or duplicated technical boundary.

Original source and prototype evidence​

Prototype and discovery boundary

Existing implementation is discovery evidence only; it establishes no current approval, acceptance, or release state.