Limits, Max, Min, Stats, etc
Written by Fidcal
This is a collection of game and map limits, maximums and minimums, etc. for the mapper to reference.
Note that some values might change as many features are still work in progress.
All units used here are Dark Radiant grid units (same as Doom 3 units.)
Conversion of game units
Main article: Conversion of Game Units
- 1.1 DarkRadiant grid units = 1 inch = 2.54 cm
- 1 DarkRadiant unit = 0.909 inches = 2.309 cm
Grid size is 131,072 x 131,072 units x 131,072 (inches) or about 2 x 2 x 2 miles
Theoretically a map might be made with about 50 stacks of 2 x 2 miles each about 200 foot high that's 100 x 100 miles or 10,000 square miles. Problem is handling the file size but it illustrates that the only limit is labour, imagination, RAM size, etc.
The limit is 8192 entities per map. However, maps should not get too close to this limit, as headroom for entities spawned at runtime has to be left.
Runtime entities are f.i. the player character, weapons, projectiles you shoot. The biggest source of "hidden entities spawned at runtime" are the combo entities. F.i. each candle or torch spawns at least a flame, fireplaces spawn the flame and possible extra wood piles, candle holders spawn a candle and the flame, a chandelier might spawn 3 candles and 3 flames etc. Note that the flames are spawned even if the entity is not lit, to allow for the player relighting it.
Another source of dynamically spawned entities are vine patches spawned by the vine arrow.
So keep your entities well below 7000 or even 6000.
It's possible to raise the entity limit in the SDK further, but usually we won't do that until it's absolutely necessary. Some of the biggest maps have currently in the range of 4000..5000 entities, and this is already pushing the boundaries in terms of memory and CPU - spawning entities costs, time, too.
To combine multiple entities into one you can use the SEED system.
There isn't a limit per say, but Bikerdude found when working on a map with 33k it would crash at compile time. What we think was happening was at compile time, brushes get split so that number goes up exponentially - http://forums.thedarkmod.com/topic/19400-brush-limit-for-tdm/
There is an additional limit of 8192 collision models (4096 before v2.04 and 2048 before v1.08).
Collision "Active Contacts"
As of TDM 2.06, collision surfaces can now have up to 128 active contacts. (Example, 128 moveable bottles on a table).
Previous versions were limited to 10.
If you exceed the active contacts limit, physics objects will float or remain stationary rather than generate physics events.
This limit does not apply to stacked objects on objects as each item in the stack has it's own physics surface with 128 available slots.
Rendering (Models, Polygons, Shadows)
There really isn't a limit on how many polygons (tris) are visible at once. Scenes with 4 million triangles might not achieve great performance, especially on older hardware, but they do run.
The renderer had a limit of 10,000 "model handles" (which roughly translates into "10,000 models visible at the same time"), but this has been increased with v1.08 to 65,537, so this should no longer be such an issue. (Defined in the source as LUDICROUS_INDEX.)
The things that affect performance most are collision models (the more there are, the harder the game has to work to test things colliding with each other, which f.i. is done for every AI that moves, for the player etc), and shadows. The more things that cast shadows, and the more detailed these shadows are, the more time it takes. However, it is not known whether there really is a limit to how many shadow tris can be cast, as it gets way too slow long before any limit is reached.
#define MAX_SHADOW_VERTS 0x18000
which appears to imply that any model with more than 98k verts in the silhouette will have it's silhouette complexity capped?
Likewise, ShadowOpt3.cpp has
static const int MAX_SHADOW_TRIS = 32768;
which again seems to be a limit on the number of tris per model?
- Minimum width a player can squeeze through = 33
- Minimum width a player can lean into = 20
- Minimum height a player can walk under = 75
- Minimum height a player can crouch through is 39
- Minimum square hole to drop into/mantle out of is 39 (length) x 33 (width.) Note that this is difficult (impossible?) to mantle up through if no sides in hole to align to (ie if just a hole in a ceiling rather than a 39 x 33 shaft, see below)
- Minimum oval hole to drop into/mantle out of is 39 (length) x 33 (width.) Note that this is extremely difficult for the player to align to even to drop down, see below.
- Minimum circular hole to drop into/mantle out of is 39 x 39 Note that this is presumed and not tested and likely to be extremely difficult for the player to align to even to drop down, see below
- Ladders need significant extra space so allow for that and test. Sometimes a ladder does not need to go through an opening but only up to it. See also the following note.
- Smaller gaps can be simulated by lining the opening with entity brush(es)/patch(es) and giving it/them the property/value: solid 0. But you need to consider the player's vision clipping into that 'simulated solid' and test this. This same technique can also be used to simulate even legitimate small/minimum sizes (ie, make the actual solid gap larger) in order to make them easier (and probably less frustrating) for the player.
- Maximum normal mantle, standing, walking, or running = 134
- Maximum jump mantle, standing, walking, or running = 182
- Minimum height to mantle onto = 1
- Minimum width to mantle onto = 1
- Minimum open wall depth to mantle onto = 1
- Minimum shelf depth to jump mantle onto from front = 16
- Minimum shelf depth to jump mantle onto from side = 16
- Minimum ledge depth to mantle or jump mantle onto from front = 16
- Minimum ledge depth to mantle or jump mantle onto from side = 16
- Minimum height of bottom of shelf to normal mantle onto = 74
- Minimum height of bottom of shelf to jump mantle onto = 122
- Maximum gap to run jump mantle over = 176
- Maximum fall without damage = 186
This varies with the different types of AI.
Humanoid AI have a cylinder size of 32, so technically they should be able to get through gaps that are larger than this. edit: I've tested gaps of 32 and AI would not attempt to path through them. Changing the gap to 36 caused the AI to path through it properly. -- Springheel
Path points closer than 16 units to worldspawn or monsterclip can cause AI problems.
Minimum doorway width a normal humanoid AI can go through = 48 (seems to contradict 32 value above?) Minimum doorway height a normal humanoid AI can go under = 88?
Slopes and Steps
The maximum slope for an AI is approximately 40 degrees from the horizontal but varies upon the situation and the AI.
The player can walk without slipping off on slopes no steeper than 45 degrees from the horizontal. If the terrain is rough this could be frustratingly difficult, however. By default, the player cannot mantle on slopes steeper than 45 degrees either (this is intended to avoid continuous-mantling exploits).
The maximum step height for AI and player is 16 though some AI cannot step up over 14 and perhaps less. But the minimum depth from front to back of a step is only 1 and this can be used to get extreme slopes and very steep steps - even near vertical walls (see Pathfinding)
Weapons and Items
- Maximum length of rope attached to the rope arrow = ~400