Engine Limits

  • If you're asking a question make sure to set the thread type to be a question!

Harribo

aa
Nov 1, 2009
871
851
Here's what it said, the image don't work so I guess it's kinda useless
I'm happy now so I've decided to write some info for beginners.

Most of us know that:

Source engine can handle 2048 dynamic entities at once.

If there are more of them, the game will quit with engine error.
engineerror1mn6.jpg


But how do we know how many dynamic entities are there at some moment? Note, that hammer entities and ingame entities is a bit different things. So, to do this:

  1. Start your map
  2. In console type "sv_cheats 1"
  3. Type "cl_showents"

This will output the complete list of all dynamic entities in the map. *Todo: does it really?*

Not to be confused, hammer entities quantity can be viewed using:

Map -> Show Information

mapinfo1cx1.jpg


Note that PointEntities and SolidEntities are hammer entities and their number does not represent ingame behavior.

So now let's talk about some common entities to destroy every myth and common mistake:

  • light and light_spot
    Any light or light_spot without name (targetname) is not a dynamic entity ingame. You can place more than 2048 lights in your map and it will work without game crashes. Any light or light_spot with name (targetname) is a dynamic entity and therefore is under 2048 limit.
  • func_detail
    Any func_detail in hammer is not a dynamic entity ingame. You can have more than 2048 func_details in your map in hammer. Also, there is no difference if u make some big multibrush object a single func_detail or each brush of it. It's the same for engine. Why? During the BSP stage of compile, vbsp analyze the vmf and mark func_detail brushes that they don't block visibility. Then it generates portal file (*.prt). After that, all func_detail information and entities are discarded and not used in VIS or RAD. *Todo: does it really? DX levels :confused:* So there is no need trying to merge all your func_details in a single entity to "reduce number of them".
  • prop_static
    prop_static is not a dynamic entity ingame. You can have more than 2048 prop_statics in your map and it will work without game crashes. Also, you can't see it's properties using "ent_text", you can't spawn it using "ent_create", you can't manipulate it using "ent_fire". But you see some info using "surfaceprop".
  • point_spotlight
    point_spotlight is always a dynamic entity. It's under 2048 limit. Plan your lights carefully or u can reach the limit very fast.
  • move_rope and keyframe_rope
    move_rope and keyframe_rope are dynamic entities. They're under 2048 limit.
  • decals, overlays - 512 overlay limit, more info soon.
  • sprites - needs some testing. Hopefully will finish in a few days.

*POST IN PROGRESS*
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
Wow, so FaTony went through and systematically purged every post he'd ever made prior to being banned?

There needs to be a plugin for VBulletin that stops people from doing that, reverts their recent edits, and auto-bans them for trying like the dickbags they are.
 

ics

http://ics-base.net
aa
Jun 17, 2010
841
540
As a tip, remember to keep your dynamic entities around 1200, 1400 if you must but don't go over that limit too much. Otherwise your map will have alone exploding teleports and other odditities, including server crashes.
 

TheONE

L1: Registered
Jan 12, 2013
26
1
Guys there was a table or a summary which showed the maximum limits of every part ... can anyone share it here plz ...
 

TheONE

L1: Registered
Jan 12, 2013
26
1
Characteristics

prop_detail
Can have 10's of thousands of them in a level. (64,000 limit in Left 4 Dead)
Can be .MDLs or sprites. Sprites are much faster to render than .MDLs.
Can be placed inside the Hammer editor or by adding a material property %detailtype to a .vmt file which causes Vbsp to automatically generate detail props over particular materials (described below).
Can never collide with them.
Are lit with a constant color (for optimization)
Don’t affect lightmaps in the world.
Automatically fade out when they exceed a particular distance from the player (controlled by the console variables cl_detaildist and cl_detailfade).
Will probably not ever be rendered on low-end hardware.
Must use models compiled with $staticprop in their .qc file.
Have no network overhead + very low memory usage.
Is not a real entity, has no inputs or outputs.
May not have animations.
Can not be hierarchically attached to other entities.
From a visibility standpoint, they are assumed to be points.
prop_static
Can have thousands of them in a level.
Can be placed inside the Hammer editor.
Can have collision associated with them.
Will affect lightmaps in the world – can cast lightmap shadows.
Will be vertex lit like standard studio models.
Will use LOD system.
User selectable as to whether the prop is rendered on low end hardware.
Fade distances can be set in Hammer editor.
Must use models compiled with $staticprop in their .qc file.
Have no network overhead + very low memory usage.
Is not a real entity, has no inputs or outputs.
May not have animations or joints.
Can not be hierarchically attached to other entities.
Optimal from a visibility standpoint, it uses the convex hull of the object.
prop_dynamic
Can have hundreds of them in a level.
Can be placed inside the Hammer editor.
Can have collision associated with them.
Will not affect lightmaps in the world, but they can cast dynamic shadows.
Will be vertex lit like standard studio models.
Will use LOD.
Will render on low-end hardware.
Fade distances can be set in Hammer.
May use models that are not compiled with $staticprop.
May have animations.
Have low (but non-zero) network overhead + higher memory usage (as much as any entity).
Is a real entity with inputs and outputs.
Can be hierarchically attached to other entities.
Optimal from a visibility standpoint, it uses the convex hull of the object.
From a visibility standpoint, they are assumed to be boxes.
prop_physics
Can have tens to hundreds of them in a level, depending on complexity.
Can be placed inside the Hammer editor.
Must have collision associated with them.
Will not affect lightmaps in the world, but they do cast dynamic shadows.
Will be vertex lit like standard studio models.
Will use LOD system.
Fade distances can be set in Hammer editor.
Are faded earlier on low-end hardware unless settings changed.
May use models that are not compiled with $staticprop.
May have animations.
Have low (but non-zero) network overhead + higher memory usage (as much as any entity).
Is a real entity with inputs and outputs.
Can not be directly hierarchically attached to other entities.
Can be constrained to other entities by various physics constraints entities.
Optimal from a visibility standpoint, it uses the convex hull of the object.
From a visibility standpoint, they are assumed to be boxes.
Additional characteristics?
prop_ragdoll
Same as prop_physics, but can use skeletons for ragdoll physics.
Has very high network overhead.


but there was a table which included all of these max numbers and the maximum number of lights ...
 

Harribo

aa
Nov 1, 2009
871
851
but there was a table which included all of these max numbers and the maximum number of lights ...

Ah yeah, i remember that, it used the Hatless upadate style of text backround shape and used bright colours for them all. I'm not sure if there's any way to recover it.
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
The maximums (and current count) for every single map-relevant limit the engine has are what VRAD spits out at the end of every compile. Just look at that.

Otherwise your map will have alone exploding teleports
The cause of that is often an extremely large (or strangely rotated) model that doesn't have collisions disabled, as attempting to teleport into the bounding box region of a model will self-destruct the teleport on the assumption the destination is bad.
 

henke37

aa
Sep 23, 2011
2,075
515
Of course, VRAD doesn't have all the limits. I've heard that some of them are actually lower than what the real engine limits are. And some are just suggestions. 815 % entdata anyone?
 

ics

http://ics-base.net
aa
Jun 17, 2010
841
540
The cause of that is often an extremely large (or strangely rotated) model that doesn't have collisions disabled, as attempting to teleport into the bounding box region of a model will self-destruct the teleport on the assumption the destination is bad.

This is not always the cause. Cashworks is a good example of this. Some of it's earlier versions had self exploding teleports, even if they didn't touch anything else than the ground. The latest version of it doesn't have this problem.
 

duppy

L1: Registered
Feb 16, 2012
35
8
vbspinfo.exe lists a lot of limits. You can find it in "Steam\steamapps\common\Team Fortress 2\bin\"

Here's an example using ctf_2fort.bsp
Code:
[FONT="Courier New"]Object names       Objects/Maxobjs  Memory / Maxmem  Fullness
------------       ---------------  ---------------  --------
models                 146/1024         7008/49152    (14.3%)
brushes               5652/8192        67824/98304    (69.0%)
brushsides           38842/65536      310736/524288   (59.3%)
planes               13042/65536      260840/1310720  (19.9%)
vertexes             29338/65536      352056/786432   (44.8%)
nodes                 7868/65536      251776/2097152  (12.0%)
texinfos              5847/12288      420984/884736   (47.6%)
texdata                291/2048         9312/65536    (14.2%)
dispinfos              232/0           40832/0        ( 0.0%)
disp_verts           13768/0          275360/0        ( 0.0%)
disp_tris            21248/0           42496/0        ( 0.0%)
disp_lmsamples      556648/0          556648/0        ( 0.0%)
faces                15768/65536      883008/3670016  (24.1%)
hdr faces            15768/65536      883008/3670016  (24.1%)
origfaces            10951/65536      613256/3670016  (16.7%)
leaves                8015/65536      256480/2097152  (12.2%)
leaffaces            20295/65536       40590/131072   (31.0%)
leafbrushes          14457/65536       28914/131072   (22.1%)
areas                   20/256           160/2048     ( 7.8%)
surfedges           120369/512000     481476/2048000  (23.5%)
edges                76265/256000     305060/1024000  (29.8%)
LDR worldlights       1857/8192       163416/720896   (22.7%)
HDR worldlights       1857/8192       163416/720896   (22.7%)
leafwaterdata            3/32768          36/393216   ( 0.0%)
waterstrips           1749/32768       17490/327680   ( 5.3%)
waterverts               0/65536           0/786432   ( 0.0%)
waterindices         31788/65536       63576/131072   (48.5%)
cubemapsamples          87/1024         1392/16384    ( 8.5%)
overlays               237/512         83424/180224   (46.3%)
LDR lightdata         [variable]     9756016/0        ( 0.0%)
HDR lightdata         [variable]     9756016/0        ( 0.0%)
visdata               [variable]      675965/16777216 ( 4.0%)
entdata               [variable]      312815/393216   (79.6%)
LDR ambient table     8015/65536       32060/262144   (12.2%)
HDR ambient table     8015/65536       32060/262144   (12.2%)
LDR leaf ambient     33616/65536      941248/1835008  (51.3%)
HDR leaf ambient     33598/65536      940744/1835008  (51.3%)
occluders               13/0             520/0        ( 0.0%)
occluder polygons       23/0             276/0        ( 0.0%)
occluder vert ind       98/0             392/0        ( 0.0%)
detail props          [variable]           1/87356    ( 0.0%)
dtl prp lght          [variable]           1/4        (25.0%)
HDR dtl prp lght      [variable]           1/4        (25.0%)
static props          [variable]           1/195250   ( 0.0%)
pakfile               [variable]    32597126/0        ( 0.0%)
physics               [variable]     2028755/4194304  (48.4%)
physics terrain       [variable]       58318/1048576  ( 5.6%)

Level flags = 3

Total triangle count: 45151[/FONT]