ITerrainPlacements

Remarks

IWaterSurface's counterpart for the ground, and it exists for that interface's reason — [35 § D1](../../docs/plan/35-water.md#d1-three-assemblies-and-the-kernel-touches-no-device), which is [31 § D1](../../docs/plan/31-terrain-grass-and-trees.md#d1-two-runtime-assemblies-and-one-editor-assembly-and-the-kernel-touches-no-device) one subsystem over. Turning a TerrainComponent's asset name into a loaded heightfield and placing it at its entity's transform is work only the render stack does today, because that is where the asset source and the extraction pass live. Everything else that needs to know where the ground is — a collider, a spawner, a navmesh bake, a dedicated server — would otherwise have to reference the renderer to find out, which puts a graphics device in a headless build.

So the renderer implements this and the rest of the engine reads it. Nothing on this interface is a device type: a Terrain is arrays and a Origin is three floats.

⚠ An empty answer is a world whose terrains have not loaded yet, not a world without ground. A .vxterrain is tens of megabytes and resolves several frames after the level is up — ITerrainAssetSource starts a load and answers null meanwhile — so a consumer that asks once at load time gets nothing, silently, and never asks again. Ask every frame; the list is cheap and a scene has a handful of terrains.

Fields and properties (1)

• int PlacementCount

  How many terrains are placed.

Methods (1)

• TerrainPlacement PlacementAt(int index)

  The placement at an index.

Used by (5)

• PlacedVixen.Terrain.Physics.Tests
• TerrainColliderSystemVixen.Terrain.Physics
• TerrainSceneSourceVixen.Rendering.Terrain
• PlacedVixen.Editor.Terrain.Physics.Tests
• ScenePlacementsVixen.Editor.Terrain.Physics