Managing the Void: Understanding BSP and PVS in Source Engine Geometry
Learn how the Source Engine uses BSP and PVS to manage visibility and collision, and why 'leaks' in your brush geometry can break your map compilation.
ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Learn how the Source Engine uses BSP and PVS to manage visibility and collision, and why 'leaks' in your brush geometry can break your map compilation.
Learn how to slash VVIS compile times and reduce runtime overdraw in the Source Engine by strategically converting decorative world brushes to func_detail.
Source Engine's Entity I/O moves gameplay logic into map data via a string-based async event bus. Covers C++ declaration model, Hammer authoring, runtime dispatch, and debugging tools for typos, coercion bugs, and circular loops.
Source Engine exposure changes belong in map logic, not client cvars. Use env_tonemap_controller and entity I/O for runtime brightness shifts that work in multiplayer.
Fix Source Engine map leaks with the pointfile, then cut VVIS compile time using func_detail, areaportals and hint brushes.
Learn how to prevent 'physics explosions' and instability in the Source Engine by managing collision meshes, mass ratios, and utilizing debug tools like phys_boxes.
Texture Scale Modifications Require Full BSP Recompile The Source engine's standard compile pipeline (VBSP, VVIS, VV) processes entire map geometry and lighting models during each build. When a single texture's scale or material parameter is modified, the compiler does not recognize this as an isolated change and instead rebuilds all lighting data from scrat