Source 2 swaps BSP for meshes and octrees

I've spent enough time in old Source maps to know when a pipeline is fighting me. BSP, brushes, weird compile waits, and that constant feeling that geometry wanted to be edited one way while the engine wanted to think another way. When I hit the Source 2 docs, I immediately latched onto the part that explains why the whole thing feels different under the hood.

Source 2 swaps BSP brushes for meshes and octree partitioning.

The trigger for this write-up is Valve’s Source 2 wiki page on the official developer site: developer.valvesoftware.com/wiki/Source_2. I’m using that page as the source of truth here, not forum lore or half-remembered engine talk. The specific line that matters to me is the geometry change: BSP and Brushes from Source are replaced with meshes, and BSP is replaced with an octree file format, .vwnod_c, for geometry partitioning.

I’m focusing on that because it’s the part that actually changes how I think about building and shipping levels. Not the marketing fluff around a new engine. The boring, annoying, practical stuff: how geometry is represented, how it gets partitioned, and what that means when you’re trying to reason about performance or editor workflow.

I stopped thinking of Source 2 as “Source, but newer”

BSP and Brushes (from Source, which goes back to Quake and Quake II), has been replaced with meshes, and BSP is replaced with octree (.vwnod_c) for geometry partitioning.

What this actually means is that Source 2 is not just a coat of paint on the old brush workflow. The engine is telling you, pretty bluntly, that the old world of brush-first level construction is no longer the center of gravity. Geometry is now mesh-based, and spatial partitioning is handled differently. That sounds small until you’ve lived through a map pipeline where every decision gets filtered through BSP logic.

I’ve run into this exact mental trap before: you see a familiar engine name and assume the old habits still apply. Then you wonder why your usual tricks feel wrong. That’s what this line clears up. The engine isn’t asking me to keep thinking in Quake-era brush terms and just “use newer tools.” It’s asking me to accept a different geometric model entirely.

How to apply it: when I evaluate a Source 2 project, I don’t start by asking “what brush workflow is the equivalent here?” I start by asking “what’s the mesh pipeline, and what does partitioning look like now?” That shift keeps me from forcing old assumptions onto a different engine architecture.

• Stop assuming brush editing is the core abstraction.
• Look for mesh authoring and import paths first.
• Treat partitioning as a separate system, not a side effect of brushes.

BSP was never just a file format, and that’s the point

People toss around BSP like it’s only a map container. It wasn’t. It shaped how levels were designed, compiled, optimized, and even debugged. In Source and its Quake lineage, BSP was part of the mental model. You built with brushes, compiled to BSP, and lived with the consequences.

Valve’s Source 2 docs explicitly call out that this lineage is being replaced. That matters because it tells me the engine team wanted to remove a whole class of constraints inherited from the old brush system. If you’ve ever had to fight with brush-based geometry because a simple shape became a compile-time nuisance, you already know why this matters.

I ran into this kind of friction years ago on older Source content: a level that looked simple in the editor could become a maintenance headache once the brush logic, vis calculations, and compile artifacts piled up. The geometry representation was doing too much work. Source 2’s move to meshes is Valve saying, in practical terms, “we’re not making you solve every spatial problem with brushes anymore.”

How to apply it: if you’re porting design instincts from Source 1, separate “how the level looks” from “how the engine partitions it.” In old workflows those were heavily entangled. In Source 2, they’re much less likely to be the same thing.

• Use meshes for authored shape complexity.
• Don’t expect brush-era optimization habits to map one-to-one.
• Read engine docs with a partitioning mindset, not just an asset mindset.

Meshes change the authoring pressure

Meshes are a different beast. They’re more expressive, they’re closer to how a lot of artists already think, and they reduce the weird translation layer between an editor primitive and the final rendered thing. That’s the real value here. Not “meshes are modern,” because that’s lazy. The value is that the authored object and the runtime object are less divorced from each other.

What this actually means is that level building gets less hostage to primitive geometry. I’m not saying everything becomes easier. It doesn’t. You trade one set of constraints for another. But the pressure shifts away from brush construction and toward asset discipline: topology, import hygiene, naming, collision, and partitioning behavior.

I’ve seen teams waste days trying to make brush workflows behave like DCC workflows. It’s always awkward. Source 2’s mesh orientation is the engine admitting that the old compromise was getting in the way. If I’m working in this environment, I want to know where the mesh boundary is, what gets baked, and what the editor expects me to hand over cleanly.

How to apply it: if you’re building tools or content for Source 2, treat meshes as first-class authored objects. Make sure your pipeline answers these questions early:

• What mesh formats are expected upstream?
• What gets generated at import time?
• What collision or partitioning data do I need to provide separately?
• What can I safely edit after import without breaking the map?

Octrees are the part I care about for performance

The Source 2 page says BSP is replaced with an octree, specifically .vwnod_c, for geometry partitioning. That’s the sentence that matters when I’m thinking about runtime behavior. Partitioning is the engine’s way of deciding what belongs where, what can be skipped, and how to organize space so the renderer and other systems don’t choke on the whole world at once.

What this actually means is that Source 2 is using a spatial subdivision structure that is more directly about dividing 3D space into manageable chunks. I’m not going to pretend the wiki sentence alone tells me every implementation detail, because it doesn’t. But it tells me enough to stop assuming the old BSP tree logic is the main organizing principle.

I’ve had enough late-night debugging sessions to know that partitioning structures are where “why is this area expensive?” questions go to hide. If you don’t understand the partitioning model, you end up blaming the wrong thing: too many lights, too many props, bad occlusion, whatever. Sometimes the real issue is that the engine’s spatial decomposition is not what you think it is.

How to apply it: when I profile a Source 2 scene, I’d want to inspect how the world is partitioned before I start random asset surgery. If the engine is leaning on octree-based geometry partitioning, then spatial locality matters. Keep related geometry grouped sensibly. Avoid dumping unrelated complexity into the same space just because the editor lets you.

That’s the practical rule I keep coming back to: partitioning systems reward discipline even when the editor doesn’t yell at you immediately.

Old Source habits can mislead you fast

The biggest mistake I see people make with engine transitions is assuming the file extension changed but the mental model didn’t. That’s how you end up trying to force old tricks into a new system and then acting surprised when the results are weird.

Source 2’s geometry note is a warning label for that exact problem. If BSP and brushes are no longer the center, then old Source habits become partial truths at best. You can still carry over some instincts about level readability, flow, and optimization, but the implementation details are different enough that the old playbook will betray you if you trust it too much.

I’ve made that mistake myself. You get comfortable. You think you understand the engine family. Then one small architectural change invalidates half your assumptions. That’s why I like source docs that say the uncomfortable part out loud. Valve did that here, even if it’s buried in a wiki page and not a big announcement.

How to apply it: audit your assumptions before you start work. Ask yourself:

• Am I assuming brush-era constraints that no longer exist?
• Am I optimizing for compile behavior instead of runtime partitioning?
• Am I treating imported geometry like it’s still an editor primitive?
• Am I reading Source 2 through Source 1 muscle memory?

What I’d tell a team building for Source 2

If I were joining a team working in Source 2, I’d want the level design and technical art conversations to happen earlier than usual. Mesh-based geometry and octree partitioning mean the pipeline has more moving parts that need to agree with each other. You can’t leave that stuff vague and hope the engine sorts it out later.

That’s the real lesson here. Not “Source 2 is better.” Not “Source 1 was bad.” Just that the geometry model changed enough to deserve its own discipline. Meshes need clean asset handling. Octree partitioning needs spatial sense. And old BSP thinking needs to stay in its lane.

I’d also want one person on the team to own the “what does this mean for our content process?” question. Otherwise everybody assumes somebody else has the pipeline figured out, and that’s how you get mismatched assets, ugly runtime behavior, and a lot of pointless back-and-forth.

How to apply it: write down the contract between your content and the engine. Don’t leave it in someone’s head. Spell out what is authored as a mesh, what is generated, what is partitioned, and what is considered runtime-only. That one document saves a ton of confusion later.

The template you can copy

# Source 2 geometry notes for a new project

## Core rule
- Author level geometry as meshes, not brush-first layouts.
- Treat octree partitioning as a runtime organization layer, not an afterthought.

## Content pipeline
1. Model the space in a DCC tool or mesh-aware editor.
2. Keep topology clean and intentional.
3. Separate visual geometry from collision where needed.
4. Export using the project’s approved mesh path.
5. Verify how the engine builds or consumes partition data.

## Questions to answer before production
- What geometry is authored by artists?
- What geometry is generated by tools?
- What data feeds partitioning?
- What data feeds collision?
- What gets baked, and when?

## Team checklist
- [ ] No brush-era assumptions in new content docs
- [ ] Mesh import rules documented
- [ ] Partitioning expectations documented
- [ ] Collision rules documented
- [ ] Profiling plan for spatial complexity

## Practical guidance
- Keep related geometry spatially grouped.
- Avoid mixing unrelated heavy assets in the same area.
- Review partition behavior when performance is odd.
- Update old Source habits only where they still make sense.

## One-sentence summary
Source 2 replaces BSP-era brush thinking with mesh authoring and octree-based spatial partitioning.

I’m not claiming the template above is Valve’s official workflow. It isn’t. It’s my distilled version of how I’d brief a team after reading the Source 2 geometry note closely. The original source gives the architectural clue; the template turns that clue into something I can actually use in a project meeting.

If you want the original wording and surrounding context, start with Valve’s Source 2 wiki page here: https://developer.valvesoftware.com/wiki/Source_2. For background on the old BSP lineage, the historical roots are worth checking too: Binary space partitioning, Quake, and Quake II. For the octree concept itself, I’d rather point people to a clean reference like Octree than pretend the Valve page explains it in depth.