Source Engine Entity Limits

Need Help? The Day isnt going so well on the Mapping front?
Post Reply
shiftey
npc_combinegunship
npc_combinegunship
Posts: 705
Joined: Thu Oct 09, 2008 4:45 pm
Contact:

Source Engine Entity Limits

Post by shiftey »

I discovered this awesome article and thought it would be incredibly useful for the mapping community. This is the original:
http://forums.tf2maps.net/showthread.php?t=3924

Source engine can handle 2048 dynamic entities at once.

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

Image

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

Image

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 * 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. Overlays and decals are static in the same way as lights. Give them a name and they become dynamic.
* sprites - You can turn them on or off so yes, they are dynamic.

Entdata
Another thing, entdata was something for HL2 to see if you are nearing the memory limit for the minimum requirements. As those are outdated that value isn't really useful.

Some others that are important for people to know that they are dynamic:
func_areaportal
func_areaportalwindow
func_brush
func_door
func_illusionary
func_lod
func_nobuild
func_occluder
func_physbox
func_tracktrain

ambient_generic
logic_branch
logic_case
logic_relay
math_counter
math_remap
path_corner
path_track
phys_constraint
filter_*
trigger_*
+any prop except prop_static and prop_detail (which you shouldnt create anyway)

This should answer almost any answer you should have about the entity limit. I'll try to keep it updated if the author adds any more to it.
User avatar
Vasili
npc_helicopter
npc_helicopter
Posts: 901
Joined: Wed Aug 02, 2006 8:22 pm
Location: England

Post by Vasili »

I already knew this, but thanks for reminding me and others.
User avatar
Tysn
Former Developer
Former Developer
Posts: 358
Joined: Thu Oct 26, 2006 1:57 am
Location: Minnesota, USA
Contact:

Re: Source Engine Entity Limits

Post by Tysn »

shiftey wrote: Image
Hate this, along with the reliable snapshot overflow error. Right now I'm in the process of updating oc_harvest and it sucks having to go around the map and having to choose which ents to sacrifice to make room for new stuff. On a side note in oc_wildfire I managed to hit the vrad limit without scaling down the lightmaps at all, but rather because the entire hammer grid is filled up with outdoor displacement areas. :P

It's nice to have all of the entity information formalized like this though; there was always a lot of misinformation about the entity limit floating around.
Image
shiftey
npc_combinegunship
npc_combinegunship
Posts: 705
Joined: Thu Oct 09, 2008 4:45 pm
Contact:

Re: Source Engine Entity Limits

Post by shiftey »

Tysn wrote:Hate this, along with the reliable snapshot overflow error. Right now I'm in the process of updating oc_harvest and it sucks having to go around the map and having to choose which ents to sacrifice to make room for new stuff.
You probably already know about this, but I might as well tell you just in case. If you have more than one group of similar entities, such as a pile of junk props for example, make them point_templates and use entity_makers. I've cut down on 60 or so dynamic entities by making templates where ever possible.
On a side note in oc_wildfire I managed to hit the vrad limit without scaling down the lightmaps at all, but rather because the entire hammer grid is filled up with outdoor displacement areas.
I hear ya. I had to cut down on my displacements for oc_holdthefort because the arena is a giant open area. Also because of this, its a nightmare to optimize. There's always 40+ pine trees in view at any given moment. :/ I might actually have to decompile the ep2 models and give them more lod models.
User avatar
Tysn
Former Developer
Former Developer
Posts: 358
Joined: Thu Oct 26, 2006 1:57 am
Location: Minnesota, USA
Contact:

Post by Tysn »

For a quicker option of optimizing the trees, one method you could use instead is to open up the trees in the model viewer and take a screenshot to make into a 2D treecard texture. Just line the model up with the camera and pick a contrasting background color (like pink or purple) for easy removal in photoshop and it will take very little time to make.

Of course treecards can only be used at extreme distances where the player's viewing angle of the tree isn't able to change much so it can't mess up the perspective, but if you do have a lot of distant trees replacing them with treecards would be a decent way of optimizing them.
Image
shiftey
npc_combinegunship
npc_combinegunship
Posts: 705
Joined: Thu Oct 09, 2008 4:45 pm
Contact:

Post by shiftey »

See I was going to do that but I had no idea that you can do it in the model viewer. Thanks for the info.
Post Reply