Levels

1Three layers and a layout

The scale of it, for High Wall of Lothric: the high collision has 1,363,951 triangles, the low 184,265, and the visual pieces are thousands of separate models data. Firelink's m40 places 4,057 map pieces of 394 models, with 1.26 M collision triangles.

2The MSB: the level's scene graph

An MSB (v1, 64-bit offsets, UTF-16 names) is a chain of tables data:

Every part shares one header:

name, type, modelIndex, sibPath,
position (3f), rotation (3f, Euler degrees), scale (3f),
mapStudioLayer, drawGroups[8], dispGroups[8], backreadGroups[8],
entityData (EntityID, …, 8 render flags), typeData (per part type), [gparam], [sceneGparam]

The gparam block names the part's light set, fog, light scattering and env map (Renderer). The entity data ends in eight render flags: casts the sun's shadow, receives it, drawn by the reflection camera, drawn only by it, and more.

Draw groups: occlusion by where you stand

DS3 doesn't find what's visible with a general visibility system. The level designers wrote it down. Draw, display and back-read groups are 256-bit masks: standing on a collision part makes its display groups active, and a part is drawn when its draw groups share a bit with them. Back-read groups keep things loaded data. In m40, depending on the floor, between 3 M and 15 M of the 24.7 M placed LOD0 triangles are visible.

3Collision parts are rooms

A collision part carries gameplay data about a region of floor, not just a mesh reference:

ConnectCollision parts say that standing on this piece keeps a neighbouring map loaded and drawn. Maps stitch together through these, not through one world mesh. Enemies and objects record which collision part they belong to, so whole rooms of characters switch on and off with the floor.

4Collision: Havok's compressed meshes

Each collision model is a Havok 2014.1 packfile using the newer hknp physics data:

hkRootLevelContainer
 └─ hknpPhysicsSceneData → hknpPhysicsSystemData
     ├─ materials[]     generic hknpMaterial (friction 1.75 …)
     └─ bodyCinfos[]    one static body, identity transform
          └─ fsnpCustomParamCompressedMeshShape      ← FromSoft's subclass
               ├─ hknpCompressedMeshShapeData         BVH + quantised vertices
               ├─ fsnpCustomMeshParameter              ← per-triangle game data
               └─ triangleIndexToShapeKey[]

• The mesh is split into sections of up to 255 primitives (a triangle, or a quad as two).
• Packed vertices are 32 bits each (11/11/10, against the section's offset and scale). Shared vertices on section borders are 64 bits (21/21/22 over the whole mesh's box). Placeholders of 0xDEADDEAD are skipped.
• A shape key is section << 8 | primitive << 1 | quadHalf, left-aligned in 18 bits. It links each triangle to its game data.

Every triangle knows what it's made of

materialNameData = slideClass × 100 + HitMtrlParam row

How it was fitted to the art: each Havok body is named after its source, an art model's hit mesh (m005590_hh) or a placed instance (m002040_1004), and a measurement shows three quarters of collision vertices lie within 5 cm of the art but only a third on its vertices. What that suggests about how FromSoftware built it is on How it was probably made.

5Water in the level

Water is three separate things in DS3's data, none of them a "water volume":

1. The surface you wade in: collision part h900300 is nothing but flat water_ankle sheets at each pond's and stream's level (y −62.25, −59.77, −69.02), 0.1-0.45 m above the bed. The bed beneath is ordinary solid collision. The wading materials are the HitMtrlParam rows with HitMtrlType1 = 2.
2. What you see: the water meshes m000010/11/12 with a water material (Renderer).
3. What it reflects: the collision parts' ReflectPlaneHeight, and a few parts marked DrawOnlyReflectCam, bands of unlit cards with 128×64 panoramas of the surroundings that stand in for the terrain in the mirror.

6Objects: doors, candles, corpses

Objects are parts with an objbnd, which can hold a model, its own collision, a skeleton and clips. Three m40 examples:

7Bonfires

A bonfire is surprisingly many things data:

8Enemies in the map

Enemy parts carry a model, an NpcParam row (its body and stats), an NpcThinkParam row (its AI), a talk id, a platoon, a walk route and an entity id for event scripts. m40 has 100 enemy parts and 43 DummyEnemy parts (cutscene stand-ins). One map holds two areas: the Cemetery of Ash and, at the same places, the late-game Untended Graves. The hollows exist in both sets, sometimes at identical positions; event scripts pick the set guess.

Our importer drops the parts whose rows are for Untended Graves (by Paramdex's names or the level-scaling SpEffect 7130/7135), 37 of them, Champion Gundyr among them. The engine places 25 Cemetery of Ash hollows of four kinds and Iudex Gundyr (Enemies).

9Regions

10Navmesh

m40_00_00_00.nvmhktbnd holds one hkaiNavMesh per navmesh part (an AABB tree and a cluster graph). The .nva links navmeshes and portals. Only the AI uses it.

11What our .scene carries

The importer merges the MSB, the area's gparam, its lights (.btl), lightmap atlas table (.btab) and probe grids (.btpb) into one .scene (v16): meshes and instances (with groups, light set, fog, LOD distances), spawns, probe cubemaps and boxes, SH probe grids, light sets, fogs, enemies, effects, lightmaps, point lights, bonfires, sound regions and animated objects. Collision goes to .col, an animated object's bodies to .objcol. The engine loads the area into a level arena and frees it by resetting the arena.