A shipped Cathode level is not just its scripts and its models. Sitting alongside those is a large amount of derived data that the engine reads at runtime but never works out for itself: which surfaces receive which lights, where NPCs can walk, what a bullet collides with, where the alien can take cover, and how sound travels from room to room.

Creative Assembly generated all of that offline, in CAGE, whenever a level was built. If you move a wall in OpenCAGE and only write the scripts back, the wall moves — but its shadow, its collision, and the navmesh around it stay exactly where they were.

File → Save and Build Level is the option that regenerates it. It performs a normal save, and then rebuilds the level's instanced data from whatever the level now actually contains.

This is the feature that makes it possible to add new geometry to a level and have the game treat it as real.

The File menu offers both, and they are not interchangeable:

• Save Level — writes your scripts, models, textures, materials and other resources. Everything derived is left exactly as it was on disk. Fast, and the right choice for the vast majority of edits.
• Save and Build Level — does all of the above, then regenerates the instanced data. Considerably slower, and the right choice whenever you have changed the level physically.

Reach for Save and Build when you have:

• Added or deleted a composite at any level down in the hierarchy from the root composite with collision data
• Ported a composite in from another level and placed it in the environment (see Composite Porting)
• Changed the shape of the areas NPCs are meant to path through
• Added or moved sound-relevant geometry — doorways, walls, room boundaries

A plain Save Level is enough when you have only edited script logic, parameters, links, or entities that have no physical presence in the world. It'll also work when moving geometry etc, but the collisions will stay in the old place.

Everything below is regenerated from the level as it now stands. You do not choose between them individually — a build runs the whole pipeline.

Geometry & Materials

• Instance materials and properties — each placed piece of static geometry gets the material it should actually be drawn with, resolved from the model's own materials, any material mappings, and any overrides applied through aliases
• Dynamic entity materials and models — particles, fog volumes and similar entities have their materials and meshes built from their entity parameters, so changing a fog colour in the inspector produces a matching material
• Zones and environment map links — which streaming zone each object belongs to, and which reflection probe it samples
• Environment animation links — the wiring that lets an animation clip drive a static mesh
• Renderable structuring — the transforms and resource links behind renderables, which used to be maintained by hand and are now generated
• Occlusion and lighting BVHs — the acceleration structures the engine uses to cull geometry and gather lights

Collision & Physics

Collision and physics instances are rebuilt to match where objects now are, including instances for newly scripted entities. This is what makes a moved wall solid in its new position rather than its old one.

NPC Navigation & Jobs

• Navmesh — generated from the ExclusiveMaster sets in the level, so NPCs path around the geometry that is actually there
• Cover — the positions NPCs and the player's pursuers can take cover at
• Job positions — spotting, crawl and assault positions used by NPC behaviours

You can inspect the generated navmesh and cover in the Viewport — see Checking the Result.

Lighting

• Radiosity — the baked bounce lighting for the level. This is the longest part of a build by a wide margin, and has its own behaviour worth understanding — see How Radiosity is Handled
• Alphalight metadata — the per-object data behind the game's volumetric light slices, for the objects that support it

Runtime behaviour is configurable under Configurations → Core Game → Radiosity (see Radiosity).

Sound

Sound networks and spaces are regenerated — the graph of rooms and the openings between them that the engine uses to route sound through the level and to decide which reverb applies where. Move a wall or open up a doorway and the sound propagation follows.

Radiosity is the one system where regenerating everything is not automatically the best answer. CA's original bakes were produced with far more time and tooling than a build in OpenCAGE can spend, so on a retail level the shipped lighting is better than anything rebuilt from scratch.

Because of that, a build patches the existing bake rather than replacing it: your new and moved objects are lit and folded into the level's existing lighting, and everything untouched keeps CA's original quality.

There are two cases where that isn't possible, and OpenCAGE falls through to a full regeneration instead:

• The level has no usable radiosity to patch — a stripped or newly created level with nothing to build on
• The level's radiosity was already fully regenerated by a previous build — at that point none of CA's original data is left, so there is nothing to preserve

When a level is fully regenerated, OpenCAGE records that fact in a small .META file next to the level's radiosity data. Later builds read it and keep fully rebuilding, rather than patching lighting that is already entirely ours.

A fully regenerated bake is dimmer and flatter than retail's — expect to spend some time on your lights afterwards. If you have a pristine copy of a level's original radiosity, restoring it before you build will give you a better starting point than letting it regenerate.

While a build runs, the progress window reads Instancing <level>…. Unlike a normal save it cannot report a percentage, so the bar runs as a marquee until the build finishes. Expect it to take substantially longer than a plain save — minutes rather than seconds on a large level.

Once it's done, two of the generated systems can be inspected without leaving OpenCAGE. In the Viewport toolbar, the State Info dropdown draws the generated Navmesh or Cover positions over the level, per state. If a region of your new geometry has no navmesh over it, NPCs will not walk there.

For collision, switch on Collision Meshes in the Render Filters panel and check that your new geometry has collision in the right place.

• Build last, not constantly. Do your script and layout work with plain saves, then build once you're ready to test the result in game. There is no benefit to building after every small edit, and it costs you minutes each time.
• Alien: Isolation is closed automatically when you save, as it holds write locks on the level files. That applies to a build too.
• A backup in progress blocks saving. If the Backup Manager is working on the level you're editing, saving is refused until it finishes.
• New geometry looks unlit in game? Check whether the level fell through to a full regeneration — see How Radiosity is Handled. Lighting on newly added objects is generated from your level's lights, so an object placed in a room with no light in it will stay dark.
• NPCs won't path onto new floor? The navmesh is generated from ExclusiveMaster sets — geometry outside those sets isn't considered walkable. Check the generated navmesh with the Viewport's State Info dropdown.

• Backup Manager — snapshot a level before building it
• Composite Porting — bring a composite into another level, optionally building it afterwards
• Radiosity — the engine-side lighting configuration
• Viewport — inspecting generated navmesh, cover and collision
• Material Mapping Editor — the remaps a build resolves when building instance materials