The Entity Limit
Parallax
Join Date: 2002-11-08 Member: 7739Members, Constellation, Reinforced - Supporter
Join Date: 2002-11-08 Member: 7739Members, Constellation, Reinforced - Supporter
<div class="IPBDescription">A wee little rant</div> Wouldn't it be great if there was no ( or a small ) entity limit? Imagine the possibilities ... Maps could be 10x more interactive. As they are now, they are little more than deserted, lifeless battlefields. With more entities, you could have areas blowing up as the karaa progress, voiceovers, lots of particle effects, switchable lights. So much possibility.
To this end, as I understand the burden on processing entities falls on the server. Having not read the HL SDK, I am not sure - but there must be a way to offload the processing of purely clientside effects to the client dll - particle effects, non-switchable func_walls, etc. Switchable lighting and stuff should be able to be controlled clientside when passed the approriate targets to call by the server. Of course most other entites (like doors, destroyable objects etc) need to be handled serverside, if we can offload some of these other entites to the client then perhaps we can get away with more entites of certian types in our maps.
250 is not much of an entity limit - for a start you use up 48 for alien spawn points, 16 for marine spawn points and 32 for ready-room spawn points. Then you take up 10 for res nodes, 3 for hives and 1 for a cc. Then you take up 3 more for the level setup entities and about 10 more for func_location entities. That is a total of 120 entities - minimum. That leaves you with 130 entites, or about 13 per room (in a 10 room map). With ambient sounds, doors and weldable spots there is very little overhead for interesting effects like dynamic lighting and damageable areas.
Part of my request is to split the entity limit into parts - for example - do func_walls use much system resources?
What are the truely nasty entites for the server - particle effects? res nodes?
I would have thought that spawn points would be quite a passive entity - they are only used when someone respawns, and then they are little more than a glorifed list of coordinates. Am I right?
Is there some way we can break through this limit?
-Parallax
To this end, as I understand the burden on processing entities falls on the server. Having not read the HL SDK, I am not sure - but there must be a way to offload the processing of purely clientside effects to the client dll - particle effects, non-switchable func_walls, etc. Switchable lighting and stuff should be able to be controlled clientside when passed the approriate targets to call by the server. Of course most other entites (like doors, destroyable objects etc) need to be handled serverside, if we can offload some of these other entites to the client then perhaps we can get away with more entites of certian types in our maps.
250 is not much of an entity limit - for a start you use up 48 for alien spawn points, 16 for marine spawn points and 32 for ready-room spawn points. Then you take up 10 for res nodes, 3 for hives and 1 for a cc. Then you take up 3 more for the level setup entities and about 10 more for func_location entities. That is a total of 120 entities - minimum. That leaves you with 130 entites, or about 13 per room (in a 10 room map). With ambient sounds, doors and weldable spots there is very little overhead for interesting effects like dynamic lighting and damageable areas.
Part of my request is to split the entity limit into parts - for example - do func_walls use much system resources?
What are the truely nasty entites for the server - particle effects? res nodes?
I would have thought that spawn points would be quite a passive entity - they are only used when someone respawns, and then they are little more than a glorifed list of coordinates. Am I right?
Is there some way we can break through this limit?
-Parallax
This discussion has been closed.
Comments
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->The guidelines limit the runtime entity count for a map, but this number isn't the same as the entity count displayed by an editor. The following entities that are removed when the map loads can be ignored for the purposes of this limit:
* info_player_start
* info_team_start
* info_location
* info_null
* light without any "targetname" (Name in Hammer's object dialog)
* light_spot without any "targetname"
There are two developer commands that mappers can use to assist in staying under the runtime entity limit: "numents" and "entityinfo". "numents" displays the current runtime entity count--running this after a map as first loaded will give the number to use for comparason to the limit. "entityinfo" displays a listing of loaded entity types with the detected count of each; mappers can use this command to find out what types of entities are contributing most heavily to the total count to help them optimize.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I agree.
As long as you use your entities wisely then 250 is more than enough in my opinion.
~ DarkATi
This would benefit greatly, if func_wall and func_seethrough could be made clientside the possibilities of details in maps could be as endless as the currently existing UT2k3 engine. If able to code, the coder would be responsible for the 'birth of a new engine'. I'm not sure it's possible, talk to Flayra or Xp-Cagey about it <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> I'm sure if it was possible they would get on the case, I would like to see this idea implemented for the HL Engine, even if it took possibly a year. Main reason is because it would be like a 5yr old engine with the standards of a 1/2yr old engine.
The func_ilusionary dont show up in the entity list... Do they count or are they clientside?
A wise man once said he who builds levels with a minimum number on func_wall entities has a low entitycount and r_speeds if one uses it correctly <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
[edit]Well it seems Cagey just answered my question in the post below this one <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->, tnx Cagey...[/edit]
What are the truely nasty entites for the server - particle effects? res nodes?
I would have thought that spawn points would be quite a passive entity - they are only used when someone respawns, and then they are little more than a glorifed list of coordinates. Am I right?
Is there some way we can break through this limit?
-Parallax<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I talked with Flayra at length about the entity limits about two weeks ago, getting a better understanding of why the limit exists and why it penalizes so many types of entities equally (although I'm pretty well versed with the tools at this point, I haven't done much with the mod SDK, and Flay and Max remain the experts on that subject). I'll pass on what I learned so that you guys can hopefully see why the entity limit is necessary and also why it doesn't descriminate among most entity types.
The first question I had for Flay was, "Is the problem on the server CPU or bandwidth?". It turns out that the bandwidth really isn't a problem, but a large number of entities really kill the CPU.
My second question was, "Do all entities cause an equal amount of problem, or do some take up more CPU than others?". The answer really suprised me--I thought it was counterintuitive, but the CPU drain from almost any entity will be about the same, give or take a few percent.
You can guess my third question: "Why do simple triggers take as much CPU time as particle systems? Isn't there more for the server to do for some entities?". Every time the server moves the game time forward, the engine code calls a function on each entity in the level to check its visibility to clients. Since this check happens with *every* server frame for *every*entity in the level's entity list, it causes a major CPU drain once the number of entities jumps above a few hundred -- even if the entities quickly return a value without doing any work, the net effect is a drain on performance that scales linearly with the number of entities. The amount of time this check takes each frame actually overwhelms the amount of time that complex entities like moving brushes take on the server, so that each entity basically takes the same amount of time when all is said and done. A trigger_multiple is just as CPU consuming as a rotating door because of this (*cough*bad design*cough**cough*).
Knowing the problem, I wanted a solution: "Can you skip the visibility function call on the server side?". The function call is built into the engine--it's not reachable from the mod SDK, and there isn't even a way to get it to call less frequently than every frame. Flay wasn't happy about this <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
I then asked about approaching the problem from another angle: "Can you remove entities from the list of items being called?". This is why some entities don't count toward the cap--items like info_player_start are actually killed when the map loads -- Flay records the position for spawning and then deletes the entity. Since the entity no longer exists, the server doesn't need to check it for visibility, and it doesn't have any effect on the CPU. This trick will only work for items that don't require any sort of interaction at run time and can be safely removed when the map loads. If you look at the list of items in the Mapping Guidelines, you'll see that each item fits that description -- all of them are static.
The bottom line: Flayra has removed entities from the server side where possible, but the design of the Half-Life engine requires all entities to be called every frame by a visibility function that ends up killing the CPU when too many entities are present. It's this drain on the server CPU that requires the entity limit for decent gameplay. Flay hasn't given up on improving server performance, but it seems unlikely that this particular problem will be solved unless Valve changes code on their end.
So does that happen with func_weldables? seen as though they are only used once?
Lets just make an official NS CPU 5.0 will do? <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
EDIT: spellings etc lol
So does that happen with func_weldables? seen as though they are only used once?
Lets just make an official NS CPU 5.0 will do? <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
EDIT: spellings etc lol <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
They have the same CPU penalty as anything else -- they aren't removed from the map because they are needed for the next round.
So does that happen with func_weldables? seen as though they are only used once?
Lets just make an official NS CPU 5.0 will do? <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
EDIT: spellings etc lol <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
They have the same CPU penalty as anything else -- they aren't removed from the map because they are needed for the next round. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
info_player_start get used on the next round, well after the first round has ended?
Nope -- info_player_start isn't used in the first round, either. The position is recorded in an array of spawn locations when the map loads and the entity is deleted when the server loads the map.
Like I said, the items that don't count toward the list are <i>static</i>. They never do anything. A func_weldable (for comparison) has to be drawn, has to interact with a welder, and may need to trigger other items when it breaks. An info_player_start doesn't have a purpose except to mark a spot on the map. It doesn't do anything in the game.
Random thought: What about, say, removing some entities from the server-side engine altogether, but sending the entity <i>data</i> in a separate process <i>directly</i> to the client? This should work for static entities, although common sense tells me this would require a fair bit of coding and won't work if the control mod code has over network data is very limited, as it is in the case of how entities are handled by the engine... (although, looking at some of the other plugins and mods... they do all sorts of wacky stuff on the client...)
Anyways, I have confidence that Flayra will figure something out. The stuff that NS has already pulled off is really amazing, especially from a programmer's perspective.
In the meantime... did you take a crack at that compiler modification for detail brushes, XP-Cagey? It would be really cool if you could get that working... <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Thanks so much cagey. That post of yours puts everything in perspective. You asked Flayra the exact same questions I would have asked... it was like reading my own conversation... <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
Now, if only there was some way of removing entities from the 'official' engine entity list and still getting them to function properly - a hack that is likely much slower than leaving it as it is.
How does the engine know what to call to check for visibility? Is it a function pointer? What happens if it is a null pointer? Crash?
Is it possible to move ambient sounds clientside?
I agree with previous posts that 250 entities is a lot to create a "traditional" map - but unfortunately that is not what I want to create. I want to create an outstanding map, one in which the damage to the map is done mostly after the marines arrive.
I also would like to mention that perhaps Valve will let you into the engine source if you ask really nicely - espcially if NS becomes commercial.
-Parallax
I'm sure valve could change something in the engine code still, but it won't likely happen unless NS goes commercial sometime soon... it would be a LOT of work for one mod. (Time they need for working on HL2 remember!)
Traditional NS can reach that limit easily, but I think combat maps will likely end up being quite "rich" with small size per number of entities. The co map I'm working on I plan on having close to the entity limit. I've also got plans in my head for a "high-end" co map that will go over r_speeds and entity limits (just for the fun of it...)
Your guess is as good as mine <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Random thought: What about, say, removing some entities from the server-side engine altogether, but sending the entity <i>data</i> in a separate process <i>directly</i> to the client? This should work for static entities, although common sense tells me this would require a fair bit of coding and won't work if the control mod code has over network data is very limited, as it is in the case of how entities are handled by the engine... (although, looking at some of the other plugins and mods... they do all sorts of wacky stuff on the client...)
Anyways, I have confidence that Flayra will figure something out. The stuff that NS has already pulled off is really amazing, especially from a programmer's perspective.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'm pretty sure that DoD has added client-side static visual elements (static map models, static func_illusionaries) that don't interact with the server and could be removed at map start. I think that unnamed ambient_generic and env_sound entities could also potentially be made client-side only, since they don't have any interaction with other map elements and are basically location data for static elements. In my conversation with Flayra, he pointed out that this is already being done for info_location entities, which aren't used on the server side. As I said in my earlier post, though, Flay and Max are the experts on the mod SDK; most of my knowledge is focused on the tools.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->In the meantime... did you take a crack at that compiler modification for detail brushes, XP-Cagey? It would be really cool if you could get that working... <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Nope <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I'm still cranking on some NS projects and p13, and I've been doing some research on radiosity methods for the new tools.
The hacks I talked about for detail brush wannabes are low priority because I don't expect them to work <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->. It would be much more productive to code genuine detail brushes into the engine and then support that from the tools vs. trying to fit a square peg into a round hole and break the basic assumptions for BSP tree storage.
<!--QuoteBegin--Parallax48+ Jan 19 2004, 06:33 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Parallax48 @ Jan 19 2004, 06:33 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I also would like to mention that perhaps Valve will let you into the engine source if you ask really nicely - espcially if NS becomes commercial.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Heh -- if Valve let Flay and Max peck at the engine source, that'd be pretty cool; I don't think it's likely to happen, though, unless Valve adopts NS like they did DoD. Although id has a history of releasing engine source, they typically do so only after their next gen tech has hit the market; Valve is still producing new games under the Half-Life engine. From what I've heard, it can be tough to get any sort of tech support from Valve as a mod maker--the Half-Life coding email list is pretty much your #1 resource, and that's community driven if I understand correctly.
and medpack? It makes me lag in the game. Someone tells me a command like
this:
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->cl_dynamiclighting 0<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
However, when I typed it on the console, it said that this command did not exist.
Did that guys give me the wrong command or what else? Can someone help me?
and medpack? It makes me lag in the game. Someone tells me a command like
this:
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->cl_dynamiclighting 0<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
However, when I typed it on the console, it said that this command did not exist.
Did that guys give me the wrong command or what else? Can someone help me? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
The command you're looking for is "cl_dynamiclights 0", not "cl_dynamiclighting 0".
I have to add, however:
I don't know what your post has to do with the topic of this thread.
I don't know what your post has to do with the topic of this forum (creating and talking about maps and mapping techniques), for that matter.
Please use an appropriate place to ask your questions in the future.
func_illusionary (rendermode additive 0 with BLACK texture or rendermode normal with NULL texture)
Is this one removed or do I have to manually remove them with Ripents after RAD?
Since it is not seen by or can be interacted with by the player. I use them in doors as a light blocker so the lights on one side of the door wont mess up the other side.
light_spot and light (without target name, but the appearance set to Fluorescent flicker or anything else not normal)
Probably client side and not included into the runtime entities?
GreetzZz Kouji San
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Nice work guys. I'm glad to see you're doing this. Bast is one of my all time favorite maps (if not my all-time favorite), and I want to keep playing it. I hope Relic gives you his best wishes on this (even though he hasn't responded to any of my e-mails either).
Also glad to hear you're not modifying it until the construction is complete, that's really the most sane approach. Also keep in mind that that the new entity limit is 275 (type "numents" to see the count).
Btw, I wrote you back Mendasp but your ISP is blacklisting me. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
so is it 250 or 275?
275 because that's the practical lower limit for many of the existing maps, but it may drop to 250 in the future.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->func_illusionary (rendermode additive 0 with BLACK texture or rendermode normal with NULL texture)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
This is not removed -- you'll need to use ripents on it.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->light_spot and light (without target name, but the appearance set to Fluorescent flicker or anything else not normal)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Lights without a target name are removed.
The listing in the Mapping Guidelines is still current in terms of what does and doesn't count toward the limit.
If an entity is killed by the map (via being killtargeted by trigger_relay for example) is it actually removed from the list of items the server calls, or it is just 'ignored'?
Another thing about map limits too is the r_speeds parameter, what limits are imposed as far as I know it is 800 limit, does this apply to the wpoly or epoly or both?
I would imagine trying to create a map that has under 200 wpoly and 300 epoly.
Dont matter what game im running or how many entities steam/half-life in game seems to use %100 CPU. When I Alt TAB out the game it's 4 - 7%
Why does it use so much CPU even with a large processor?
I used to have 450 Mhz comp, 100% CPU, Game ran okay but the cpu choked graphics.
This 1.7 GHz AMD ATHLON, still 100% CPU usage in game...
WTH is going on? Why it use more cpu the bigger it is?
Im sure its chokeing my graphics card a lil bit all this useage!
Maps would run more smoothely if their was some CPU to spare I think! <!--emo&::asrifle::--><img src='http://www.unknownworlds.com/forums/html//emoticons/asrifle.gif' border='0' style='vertical-align:middle' alt='asrifle.gif' /><!--endemo--> <!--emo&::gorge::--><img src='http://www.unknownworlds.com/forums/html//emoticons/pudgy.gif' border='0' style='vertical-align:middle' alt='pudgy.gif' /><!--endemo-->
I used to have 450 Mhz comp, 100% CPU, Game ran okay but the cpu choked graphics.
This 1.7 GHz AMD ATHLON, still 100% CPU usage in game...
WTH is going on? Why it use more cpu the bigger it is?
Im sure its chokeing my graphics card a lil bit all this useage!
Maps would run more smoothely if their was some CPU to spare I think!<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
In half-life the CPU has to use alot of power for the actual rendering. This is done every single frame that is drawn. If you get a better processor your graphics card will get more work to do but your processor is still the bottleneck.
What takes so much CPU usage? I'm pretty sure it is the transformation of every single polygon in a model(rotation and translation), the blending of model animation steps(there is only a certain amount of frames that models have for a certain motion, these are blended between to get intermediate steps.).
Alot of these transformation and lighting operations can be offloaded to the graphics card today, but half-life doesn't do this. Even a geforce 4 mx-440(infamous as a piece of junk) can render 200 000 polygons per frame at ~60 FPS in a new game like stalker oblivion lost and look pretty damned good.