TrenchBroom Theory

A collection of observations on mapping techniques, and tips for best-practices, workflow and efficiency.

CSG Subtract vs Brush and Clip tools

• CSG Subtract

  • Creating concave indents in existing brushes is more intuitive
    • Brush tool defines both outline and depth
  • Subtracting complex geometry creates microbrushes and microleaks
  • Can't control subtract splitting unless you pre-clip enough of the mesh to reduce the problem to a single-solution set of triangles
    • Need to tightly clip a rect and keep your vertices on its edges
  • Considered a newbie trap in Q1/HL mapping
    • Fractures meshes and creates bad geometry
    • Instant results, but causes major long-term maintainability issues

• Clip / Brush Tools

  • Less immediately intuitive for convex indenting
  • Requires good technique
    • Practice necessary
  • Better geometry is worth it
    • Empowers the other tools
    • Forms the basis for advanced usage
    • Can create complex architecture but retain simple, editable shapes
    • More maintainable
  • Workflow can be optimized with key shortcuts
    • Clip Tool: C
    • Swap Cutting Edge: X
    • Perform Clip: Z

Clipping techniques

• Covered in layman's terms in the dumptruck video that covers arch creation

  • Manually clip convex arch shape into one triangle per face
  • Anchor clips to the nearest upper corner, better for curves
  • Results in cleaner geo, prevents QBSP from creating triangle soup

• Generalized usage

  • Clip bounding box brushes into vertical bar slices per-face
  • Perform further clips to define bounding rect brushes for internal convex faces
  • Face / edge edit resulting brushes to create actual convex faces
  • Join internal brushes into convex geo, prioritizing diagonals
    • Empowers the extrusion tool, as it respects the shape of neighbouring edges
      • Technically manipulating .map clip planes directly rather than the edges themselves

• Deeper theory important to explore, informs more generalized application

  • Axial splitting forms the basis
  • Why are vertical splits the default?
    • Wall detail is the most common use-case
    • Theory: Detail flows horizontally in most room architecture
      • Humans naturally prioritize horizontal attention in most cases
        • Two eyes separated horizontally
        • Wider horizontal FOV
      • Tall or vertically open areas an exception
        • Vertical negative space as a feature, diverts attention
  • Are horizontal splits ever preferable?
    • Horizontal splits will happen within vertically-split brushes
      • Problem of scale?
    • Geometry detailing for a column
      • Taller than it is wide
  • General rule: split along the shorter UV axis
    • Helps for dealing with floors, ceilings, arbitrary architecture
    • This isolates the detail brushes from their source brush immediately
    • Prevents clips from interfering with existing geometry and creating extra convex merge work
  • Priorities when clipping
    • Extrustion friendliness
      • Extrusion is incredibly powerful with good source geometry
        • Directly manipulates brush planes by their normal
        • Bal curves a good example
        • Creating techbase (and other) architecture by manipulating primitives
        • Prioritize diagonal splits rather than sticking to world axes
    • Maintainability
      • Prevents time that could be spent mapping from being wasted on fixup work
    • Geometry optimization not a priority for QBSP workflows
      • QBSP will combine and re-split coplanar points that share texture offsets
      • In some cases triangle optimization and extrusion optimization are the same
        • Arches, for example

• Do not share walls between rooms

  • If you need to detail, split them along their longest axis first so each room has its own wall
    • This prevents any further splits from having adverse effects on existing geometry

• Split early rather than trying to make your brushes as large as possible

  • Ex. Using a large floor brush to denote area footprint, then carving it up into corridors
  • Ensures that textures are properly aligned to visible edges at creation time, rather than texturing time

• Generalizing into 3 dimensions

  • Terrain editing is a good example case
    • Splits a single brush biaxially
    • Detail is defined by moving vertices along the third axis
      • Or extruding faces within a hemisphere oriented along the third axis
    • Applying the 2D theory in two dimensions simultaneously
      • Less opportunity for optimization by recursive splitting
        • Many splits already happening, necessary

Workflow Optimization

Work passes

• (Optional) Fully detailed and textured start room

  • Helps with defining a visual theme for the map
  • Can inform geo styling without requiring every room to be textured

• Greybox

  • Define the rough outline of your map
  • Worldspawn geometry
    • Stick to simple shapes
    • Use this pass to define what will be VISed
  • Gameplay-first design
    • Ensures the map is fun before it's pretty
    • Massively speeds up time-to-playable at the expense of visuals
  • Use khreator's prototype.wad to clearly denote untextured rooms
    • Can use colors to define each room's aesthetic in broad terms
    • Disable UV and texture lock during greyboxing
      • Baked-in grid helps keep your architecture aligned during creation
      • Prevents annoying UV reset fixups come texturing time

• Detail and texturing

  • Finer geometry using func_detail
    • Doing this post-greybox ensures that VIS is locked down

• Sometimes detailing can creep into greyboxing

  • Good if you're hit with an idea and need to realize it ASAP
  • Need to be careful it doesn't turn into procrastination
    • Ties back into making sure the map is fun before making sure it's pretty

Categorization and grouping

• Ignored by the engine

• func_group

  • Specific to Q1 format (not available in Q2)
  • No focus nesting, grouped entities can be selected individually
  • Double click to select all
  • Easier editing, but more potential click targets
  • Best for worldspawn geo grouping and lightweight contextualization

• TrenchBroom groups

  • Stored using TB-specific metadata properties
  • Nested focus, can only edit entities inside the currently active group
  • Double click / cancel to navigate group tree
  • Best for prefabs Ex. light fixtures with built-in light entities

• TrenchBroom layers

  • Stored using TB-specific metadata properties
  • Can control locking and visibility per-layer
    • Useful for hiding obstructive elements during geo editing
      • Clip brushes, triggers, gameplay entities, detail brushes
  • Better for broad-strokes categorization ex. world geo, lighting, gameplay entities
  • Arguably obsoleted by toggleable view layers
    • Fine-grained control of visibility
    • Much more complex, requires extensive hotkeying to be viable

Hotkeys

• Hotkeys are well worth the time investment
• The less you have to move your hands off the home row / mouse the faster you can work
• Constantly self-reflect on your process, spot common time-sink actions, and optimize with hotkeys where appropriate
• Actual hotkey bindings will vary by individual
  • Intuition is subjective, since everyone has their own mental proces
• Helps to group things contextually, or using a mental metaphor
  • Ex. tools on ZXCVGT, extended tools (dupe, flip, rotate, etc) on Shift + ZXCVGT
  • Modifier key as a 'more powerful' version of an existing action
    • Ex. binding cancel to space, and delete to shift + space
      • Cancel is a 'negatory', deletion is an applied / empowered 'negatory'
      • No need to move hand for deletes

Map Hacks

• Entity index (found by using the edicts console command in-game) can be used with the owner property to create complex behavior
  • Ex. Aggro targets
• In-map entity order can be controlled to a degree using TrenchBroom layers
  • Entities in saved .map files are grouped top-to-bottom in the same order as the editor UI
  • Allows for somewhat deterministic control over an entity's edict index
  • Currently no way to reorder layers
• Entity count / indices are determined on map start
  • Difficulty-dependent entities interfere with edict indexing
    • Potentially different position in list
  • Having more or less entities based on the difficulty will change indexing
  • Solution: Place all difficulty-dependent entities in the last layer and don't use edict index hacks on them
    • Theoretically possible to still use hacks with difficulty-dependent entities, but likely to become very messy
  • Entities whose indices need to be known should be placed in their own (topmost) layer for easy referencing