Skip to main content

AEROSIM-TS-167

Project task

Build lightweight AeroSim-owned terrain and space GLBs

Training Airfield, Coastal Range, and Mountain Valley use purpose-built lightweight AeroSim world geometry that remains visually distinct and navigable while reducing browser download, parse, memory, and rendering cost.

AEROSIM-TS-167Canonical ID TASK-0167
Verified flow state
Unverified
Owner
AeroSim Architecture and Delivery
Component
3D assets — AeroSim-owned terrain and environmental geometry
Repository
corp-v1-aerosim/corp-v1-aerosim

Delivery scope

Create new simplified terrain and environmental-space geometry without copying third-party mesh topology; preserve the three governed world identities and required runway, water, mountain, horizon, spawn, scale, collision, height-sampling, and navigation cues. Keep AeroSim-owned sky, lighting, boundaries, physics, and interaction contracts separate. Use compact materials and textures, deterministic export, explicit budgets, and governed manifests. Keep every existing source and runtime GLB unchanged until exact replacement acceptance passes.

Implementation contract

Implementation artifacts

  • assets/source/aerosim-owned/worlds/
  • assets/runtime/aerosim-owned/worlds/
  • assets/manifests/aerosim-owned-world-*.json
  • packages/assets/scripts/build-aerosim-worlds.mjs
  • packages/assets/tests/aerosim-owned-worlds.test.ts
  • applications/web/e2e/aerosim-owned-worlds.browser.spec.ts

Inputs

  • Governed world roles, mappings, spawn points, scales, boundaries, collision and height contracts, and production screenshots from AEROSIM-FT-45.
  • Existing terrain GLBs as runtime and visual comparison inputs only, subject to their provenance and without copying protected mesh topology.
  • RootAtSkic direction to create AeroSim-owned lighter and simpler spaces and terrains.

Outputs

  • Deterministic source and runtime GLBs for Training Airfield, Coastal Range, and Mountain Valley.
  • Per-world manifests with authorship, source-separation evidence, dimensions, landmarks, hashes, bytes, triangles, vertices, materials, textures, draw calls, and estimated GPU memory.
  • Production-browser comparison evidence proving world identity, runway or water and mountain cues, spawn and collision correctness, camera usability, and measured runtime improvement.

Failure boundaries

  • Fail when an output copies third-party source mesh topology or lacks auditable creation and authorship evidence.
  • Fail when worlds are not visually distinct or required runway, water, mountain, horizon, spawn, scale, collision, or navigation cues are missing or wrong.
  • Fail when the replacement does not materially improve agreed byte, geometry, material, texture, draw-call, parse, and GPU-memory budgets.
  • Fail when any original source or runtime GLB is overwritten before replacement acceptance.

Excluded scope

  • Do not change flight physics, weather behavior, world-selection semantics, boundary rules, or licensing records for retained third-party assets.
  • Do not start implementation until the Feature is approved and the Task is admitted from IN_BACKLOG.

Verification steps

  • Establish measured baselines and approved budgets for all three governed worlds before creating replacements.
  • Export each new GLB twice and require deterministic hashes, self-contained resources, valid manifests, and all budgets to pass.
  • Exercise ordinary production setup and long-flight journeys in every world and required camera; verify identity, landmarks, spawn, collision, height, horizon, and visual integrity.
  • Verify originals remain unchanged and runtime mapping changes only after exact reviewed acceptance evidence exists.

Traceability

Requirements

Dependencies

UI/UX applicability

Unclassified

Acceptance evidence

Required future evidence: all three governed world roles must have independently authored deterministic GLBs, complete provenance and budget manifests, material runtime reduction, and passing ordinary production-world and long-flight acceptance before any runtime replacement.

Current evidence boundary

No current implementation, acceptance, release, or deployment evidence is claimed for this planned Task. Any prior implementation may be used only as prototype and discovery evidence.