Making the Procedural Buildings of THE FINALS

That system eventually became what the team now calls Building Creator.

Below, Adrian Björkerud will break down the system and some of the tool design decisions that make their fully destructible buildings possible.

Destruction adds a unique layer of complexity to creating buildings for games. Many shortcuts that are common in traditional 3D content creation no longer apply when assets are meant to be fully destructible, traversable, and interactive.

For example, in many games, buildings are just facades (empty shells with no interiors) because players never enter them. In THE FINALS, however, players are expected to enter, traverse, and even stand on every part of a destructible structure. This means every building must have complete interior spaces, including hallways, staircases, rooms, and attics: all with accurate collision.

Another constraint when creating destructible buildings for most games is that all geometry must be fractured beforehand, not during gameplay. Real-time fracturing is generally too computationally expensive and unpredictable for a fast-paced multiplayer game. Instead, all destructible assets in THE FINALS are pre-fractured into smaller pieces in Houdini, with seams carefully hidden until the asset is damaged, for example by gunfire or explosions.

This fracturing approach requires the input geometry to be fully watertight (no open edges or disconnected surfaces) so the tool can generate clean interior faces automatically.

All of this means that creating content for THE FINALS requires a different mindset. Even though the team now has a robust pipeline in Houdini, where fracturing and iterating on a building can be done in just a few minutes, it still requires artists to think one step ahead: ensuring watertight geometry, properly authored collision meshes, and clean topology from the start.

Many procedural building generators are designed around a specific architectural style, which is a perfectly valid approach, especially in games where visual consistency is a priority and most buildings follow a shared visual language.

Over time, Adrian Björkerud has come to see that procedural tools in general often fall into two broad categories:

• Rigid Tools: They typically expose only a handful of parameters, enforce consistency, and minimize room for user error. Tools like automatic UV unwrappers or LOD generators fall into this camp: their value is in making repetitive work efficient and predictable.

• Creative Toolsets: Instead of one rigid path, they provide a collection of flexible building blocks that artists can combine in different ways to achieve a wide range of results. A good example is SpeedTree, where users can wire nodes together to build anything from a palm tree to an old oak.

This modularity offers several key advantages:

• Creative Freedom - Artists can choose which features a building should have, and combine them in ways that fit their needs.

• Scalability - New features can be added over time with minimal risk of breaking existing content.

• Maintainability - Since nodes are loosely coupled, bugs or improvements can often be isolated to individual nodes.

• Faster iteration - Because each feature node has well-defined dependencies, small changes only recook the parts of the graph that need it. Adjusting a window won’t force a full building to recook.

The Building Creator node is an Object-level HDA that represents a single building. It exposes a small set of global parameters, such as wall thickness, floor height, and other building-wide settings that feature nodes often need to stay in sync on.

Inside its SOP dive network is where the building is actually assembled. Artists drop in Feature Nodes here and wire them together to define the node structure. The Building Creator node itself doesn’t generate geometry; it provides the shared context and the framework that Feature Nodes operate within.

Feature Nodes are SOP level HDAs and live inside the Building Creator node’s SOP dive network. Each one generates a specific architectural element: walls, foundations, floors, roofs, windows, doors, and so on. In other words, each Feature Node represents one feature of a building.

Most Feature Nodes are order-independent, meaning they can be arranged in almost any sequence, with a few logical exceptions, like needing walls before placing windows. Many of them include custom viewer state tools to make user input more direct and intuitive in the viewport. For some nodes, these tools are essential to their workflow.

Feature Nodes generally have two inputs and two outputs.

• The first input/output carries the building geometry that each feature adds onto.

• The second input/output passes along a blockout mesh and additional auxiliary data, which downstream nodes can use for alignment, placement, or further processing.

Once the blockout is referenced on the Building Creator HDA, the artist dives into its SOP network. This is where the actual assembly happens: the blockout and generated geometry flow through the network, and Feature Nodes are dropped in to layer on architectural features.

A typical workflow looks like this:

1. Reference a blockout mesh on the Building Creator HDA.

2. Dive into the Building Creator HDA's SOP network, where the blockout is automatically fed into the Feature Node chain.

3. Add Feature Nodes in whatever order fits the building—walls, floors, windows, roofs, details, etc.

4. Each Feature Node reads the incoming geometry stream and contributes its feature on top of it.

5. Collision and occluder generation runs at the end of the chain, since these don’t require artistic input.

This structure keeps the workflow flexible: artists choose which features to include and how to combine them, while the node chain handles data flow and dependencies automatically. From a development standpoint, it also keeps debugging straightforward, since every part of the building’s assembly is visible inside and ordered in the network.

With that clarification in place, the next step is to examine some of the core Feature Nodes and how they are used in practice.

The Exterior Walls Feature Node generates wall geometry structured by horizontal edge loops separating floors and a dynamic set of vertical loops subdividing the facade. This structured topology serves as a foundation for downstream tools, enabling the placement of windows, application of materials, and insertion of architectural details like cornices, moldings or other elements.

The node includes a custom viewer state that offers intuitive control over the topology generation. Artists can interactively adjust the spacing of vertical edge loops per wall segment and corner, giving them fine-grained control over wall segmentation.

The Floors Feature Node generates structural floor slabs for each story of the building, aligning them to the inner faces of the exterior walls. The node exposes three primary parameters:

• Floor Height – vertical spacing between slabs.

• Floor Thickness – thickness of each slab.

• Clearance Threshold – minimum space required between a candidate slab and the ceiling above, slabs are not generated if the available height is below this threshold.

The Room Feature Node takes an input mesh volume that intersects the building. Along those intersections it generates interior walls and tags all enclosed geometry with an identifier (e.g., "LivingRoom"). These identifiers act as tags that can be referenced downstream, allowing other Room Feature Nodes to selectively create sub-rooms or avoid generating rooms at all in specified areas.

Alongside the Room Feature Node is the Room Style Feature Node, which defines the visual identity of a given room type. It uses the identifier (e.g., "LivingRoom") to apply style-specific elements such as moldings, cornices, lamp sockets, electrical outlets, radiators, and unique material assignments.

This separation of spatial definition and stylistic decoration makes it easy for environment artists to iterate and customize interior spaces with both consistency and flexibility.

When the team began using these tools when making the Monaco map, they quickly realized that the sheer number of interior spaces could cause massive confusion during gameplay. The map contains more than 30 unique buildings, each with one to five floors plus an attic. On paper, this was great for variety, but in practice, it risked overwhelming players with layouts that felt unpredictable and inconsistent.

To solve this, the team established a clear interior ruleset that all Monaco buildings follow:

• On the ground floor, the main entrance door always opens into a hallway with a staircase on the left-hand side.

• On the right-hand side of that hallway, there’s always an exit door, so players can run straight through the building.

• At the top of the stairs, there’s always a hatch leading into the attic.

This consistency meant that once players had explored one Monaco building, they could intuitively understand the others, even though each had its own unique facade and details.

The team also experimented with placing furniture in the interiors but quickly found it clashed with the game’s pace. Players moving at full sprint would constantly snag on chairs or tables, so they stripped furniture back to keep traversal smooth and predictable.

By pairing their procedural room generation with these design rules, the team ensured that Monaco’s buildings stayed varied enough to feel real, while still being readable and playable in the heat of combat.

Feature Nodes typically copy, move, deform, and merge these custom meshes into place, using the building’s blockout mesh as a guide. This gives artists full control over the visual identity of a building: they can create modules with any shape, detail level, or material setup, as long as the input mesh is prepared to match the tool’s expectations.

Some features, such as windows and doors, require openings in walls or other parts of the building. These are in the tools often referenced as Modules, and are made up of three different kinds of components:

• Visual Meshes - which are the actual meshes seen in-game, and part of the building mesh.

• Boolean Meshes - used to cut holes in building geometry where necessary.

• Mesh Sockets - used for spawning additional details in engine.

This workflow allows for a Module to have any profile or shape being cut out of the surface of the building, enabling curved archways, or circular windows with no extra work.

The concept of Modules isn’t tied to a single node or workflow. Instead, it’s a flexible building block used across several Feature Nodes, each tailored to different use cases. One of the most versatile and widely used of these is the Manual Module node.

• Snapping to key architectural features, such as different surfaces, edges, or floor lines.

• Manual transformation (move, rotate, scale) of each placed module in local or global space.

• A Boolean filter which controls which parts of the building geometry are affected by booleans.

Each Manual Module Node typically handles one type of module, for example, a door in one node and a window in another. These nodes are then chained together inside the main Building Creator node to build up the full set of modular features for a given building.

This approach allows for maximum control and flexibility, letting artists place complex or unique elements exactly where they want them, while still benefiting from a procedural pipeline.

The Exterior Decals Feature Node helps buildings feel grounded and believable. It automates the generation of procedural mesh decals. These subtle overlays help break up uniform surfaces and add the small details that keep buildings from looking too clean or artificial.

The buildings mainly use two different types of mesh decals:

• Edge Softening Decals - Adds fine normal detail along hard mesh edges to smooth out harsh shadow borders and create more natural-looking transitions.

• Grout and Leak Decals - Visually connects the different elements of the building along the intersections between modules, exterior cornices and walls. Optionally, users can replace the bottom region of exterior cornice decals with a leak decal, introducing subtle weathering effects.

In a fast-paced FPS like THE FINALS, collision accuracy is critical to gameplay. Every bullet, explosion, and player movement relies on collision meshes that are both reliable and efficient. If a wall blocks a bullet it should not, or if a player gets caught on invisible geometry, it can directly affect the outcome of a match.

Manually creating collision meshes for hundreds of destructible buildings would be slow, repetitive, and error-prone, and it would take up a significant amount of environment artist time. Automating collision generation therefore became an important part of the toolset, improving iteration speed while allowing artists to focus on higher-level creative problems rather than repetitive cleanup.

Each Feature Node stores a simplified planar representation of its geometry (typically hidden from view). These shapes are later used to generate accurate collision hulls. The planar data is triangulated and processed through a custom 2D convex decomposition algorithm written in VEX, running iteratively in a feedback loop. The resulting convex polygons are then extruded into 3D space to produce the final collision hulls.

This showcase goes through the full pipeline of the Building Creator toolset: first recreating a building from the Bernal map, then revealing its post-fractured setup in Houdini, and finally showing the fully destructible version as it appears in THE FINALS.

The Building Creator toolset also saw use outside THE FINALS, most notably on Buried City, the sand-swallowed Italian town in ARC Raiders. For this map, the tools were used only to generate the base building meshes, since ARC Raiders does not feature fully destructible environments.

In THE FINALS, details like moldings and door frames need to be part of the main building mesh so they can follow the fractured pieces when a wall breaks apart and falls. Since ARC Raiders does not have this requirement, these details were more efficient to place as instanced static meshes. The ARC Raiders environment art team added most of the visual details and set dressing directly in engine, using the generated buildings as a clean and consistent starting point

• Iteration speed: From blockout to fractured asset in ≈ 4–6 minutes per change.

• Scale: 100+ unique buildings shipped across two games, THE FINALS and ARC Raiders

• Collision & Occluders: Fully automated, zero manual authoring.

With that, the full system has been covered, from a simple blockout mesh in Houdini to a fully destructible, playable building in THE FINALS. Developing this pipeline proved to be as much about making tools as it was about building buildings, and several key lessons emerged from the process.

The fastest way to make an unused tool is to over-polish it before showing it. Get something usable into artists’ hands early, then iterate with them. Most of Building Creator’s best ideas came from “what if we could…” moments from the Maps team. Building Creator has been in continuous use and development for over five years, and it continues to grow through that same iterative process.

Over a multi-year project, skills and goals evolve. A modular design allows individual nodes to be replaced or upgraded without breaking the rest of the system. Like a large codebase, clean separation between systems keeps things maintainable.

Developing Building Creator was a team effort from day one. Adrian Björkerud led the design and development of the toolset, while the THE FINALS Maps team and environment artists shaped it through daily feedback, stress-testing features, finding edge cases, and helping make it production-ready.

Embark gave him the freedom to explore a procedural approach to one of the game’s defining pillars, fully destructible buildings, and that trust made this possible.

This article focuses on the core ideas behind the system. There is much more under the hood, including additional Feature Nodes, Python Panels, LOD tagging, and destruction setup, that could be explored in a future deep dive.

Most of what is shown here, including materials, props, and assets, was created collaboratively across the studio. The toolset helped bring those elements together.