Source Map Limits: Brush, Entity and Size Limits Explained
Source map limits at a glance: coordinate space, brushes, entities, displacements and lightmaps, typical MAX_MAP errors and how to stay below them.
A Source map is limited in several directions: in coordinate space (±16384 units per axis), in the number of brushes, brush entities, faces, displacements and overlays and, at runtime, in the number of entities. Garry's Mod has raised several of these limits well above the Source SDK 2013 defaults. If you exceed a limit, the compiler aborts with a message such as MAX_MAP_BRUSHES, or the game crashes while loading or during play. The main countermeasures are props instead of brushes and merged entities.
The most important limits at a glance
| Limit | Garry's Mod | Source SDK 2013 | What counts |
|---|---|---|---|
| Coordinate space | ±16384 units per axis | ±16384 units per axis | the entire map including the 3D skybox |
| Brushes | 65535 | 8192 | every brush, including func_detail and brushes inside entities |
| Brush entities | 4096 | 1024 | every entity made of brushes, such as func_door, func_brush or triggers; the world itself takes one slot |
| Planes, faces, vertices | 65536 each | 65536 each | the compiled geometry |
| Displacements | 16384 | 2048 | every displacement face |
| Overlays | 8192 | 512 | every info_overlay |
| Lightmap data | no maximum in the usage table | 16 MB in the header, no maximum in the usage table | all lightmaps combined |
| Edicts at runtime | 8192 | 2048 | networked entities in the running game |
For the compile limits, the Garry's Mod column shows what GMod's own compile tools print as the maximum in their usage table (build of September 2026). The table names no maximum for displacements, so 16384 is the figure from the Valve Developer Community wiki, which a test compile confirmed. The edict limit is also the one that wiki gives for GMod. The SDK column holds the defaults from the Source SDK 2013 source code, which older lists usually quote. Community compilers differ again. The table in the log of your own compiler, described further down, is always authoritative.
What the coordinate space means
The grid in Hammer ends at 16384 units in every direction. A map can therefore be at most 32768 units long, wide and high. At roughly 1.9 centimetres per unit that is a little over 600 metres along each edge. No geometry can be created outside of it.
In practice you rarely hit this wall first. Very large, open maps fail earlier because of the visibility calculation and the frame rate. Wide landscapes are better faked with a 3D skybox, which is built at 1:16 scale and therefore takes up little room.
How you notice that you are hitting a limit
- Compile errors: VBSP or VRAD abort and name the affected limit, for example
MAX_MAP_BRUSHESorMAX_MAP_PLANES. How to find such messages is shown in Read a compile log. - The usage table: At the end of the VRAD log there is a table showing, for every data section of the BSP, the used and the maximum amount plus the fill level in percent. When a value approaches its maximum, the compiler marks the line with
VERY FULL!. Sections without a fixed maximum, such asdispinfosand the lighting data, show a 0 there and are never marked. Look at this table before every release. - Crash in game: If all edicts are in use at runtime, the game quits with a message such as
ED_Alloc: no free edicts. This often only happens on a full server when many players spawn props. - Hammer refuses: Objects cannot be moved past the edge of the grid.
If you cannot place a message, paste the log into the Map Scanner. It detects root causes and follow-up errors in VBSP, VVIS and VRAD logs. Known messages are also listed in the error database.
Countermeasures for geometry
- Props instead of brushes. Railings, pipes, furniture, arches and other details with many faces belong in models. A
prop_staticcounts neither as a brush nor as a runtime entity, because it is written into the BSP permanently. - Simplify brushwork. A few large brushes are better than many small ones. Sliced leftovers from the Carve tool drive brush and face counts up for no reason.
- Understand
func_detailcorrectly. It reduces visleafs and portals and thereby shortens VVIS. It does not relieve the brush limit, because a detail brush is still a brush. More in Optimize GMod map performance. - Use displacements sparingly. Use a few large faces instead of many small ones and no higher resolution than necessary. Distant terrain moves into the 3D skybox or into a model.
- Relieve the lightmaps. Raise the lightmap scale on large faces that do not need sharp shadows. The tools name no fixed maximum for lighting data, but it makes the BSP larger.
Countermeasures for entities
- Merge brushes into one entity. Ten window panes as ten
func_brushentities take up ten slots. If you select them all and tie them to one entity together, it is one. If they need no entity function, they becomefunc_detailand take up none. - Prefer static props. Anything that never moves becomes a
prop_staticinstead of aprop_dynamicorprop_physics. - Leave lights unnamed. A
lightwithout a name is baked into the lightmaps and no longer exists as an entity in game. Only name lights you really want to switch. - Count effects. Sprites, ropes, particles and sound sources are harmless individually but noticeable in large numbers. Some entities create additional helper entities in game.
- Plan a reserve. On a server, players, weapons, vehicles and spawned props come on top. A map that is close to the limit while empty will not run reliably in operation.
FAQ
How large can a GMod map be at most?
The coordinate space runs from -16384 to +16384 units on each axis, so 32768 units along each edge. That corresponds to a little over 600 metres. Larger worlds only appear larger through a 3D skybox.
Does func_detail count as a brush?
Yes. A func_detail counts towards the brush limit, but not towards brush entities and not as an entity at runtime. Its benefit lies in the visibility calculation.
What does VERY FULL! mean in the compile log?
The marker appears in the usage table at the end of the log and shows that a data section of the BSP is almost full. The map still works, but has hardly any headroom for more content. Reduce the specific section named in that line.
Can I raise the limits?
Not through settings in the map. The limits are defined in the compile tools and in the engine. Garry's Mod has raised several of them in its updates, for example the overlay limit to 8192 in March 2024. The only reliable approach is to build the map so that it stays below them with a reserve.