Welcome to PlagueFest.com! Log in or Sign up to interact with the Plague Fest community.
  1. Welcome Guest! to interact with the community and gain access to all the site's features.

What sort of limits are there when making a map?

Discussion in Mapping Discussion started by Trond, Dec 3, 2013

  1. Jul 20, 2012
    What kind of limits does a map have before the server can't load the map or having a meltdown during gameplay?
    Trond, Dec 3, 2013 Last edited by Trond, Dec 26, 2013
  2. Apr 9, 2012
    Envio and Luffaren knows all of these
  3. Jan 30, 2013
    2048(the entity/edict limit) Hit/pass this magical number, and you'll implode the Source universe.
    that's all I got for now
    RedM00N, Dec 3, 2013 Last edited by RedM00N, Dec 3, 2013
  4. Feb 24, 2011
    The most common limit would probably be the entity/edict limit.
    Servers will crash when it reaches 2048 entities, although i believe it can actually be cranked up to 4096 because apparently there's 2048 entities for "active" stuff (like triggers, buttons, doors, dynamic props etc) and 2048 entities for "logic" stuff (like logic_math, logic_timer etc)
    There's also a whole deal about entity "edicts" that it depends on.
    A strong recommendation would be to keep it as low as possibly possible, 1400 ents would be the max-recommended (because a full server with players that have bought as many weapons/items as they can takes around ~650 ents, as you might want/need to spawn extra stuff in the round or the server itself might have some plugin that needs X amount of ents, for hats/trails/etc)
    Also remember, there are a handful of entities that doesn't count towards the limit (like prop_static, light, light_enviroment *light without names*, decals, func_detail. Mainly things that are deemed "static")

    Then there's a thing called "IN" which you can see with "net_graph 1-3".
    IN is pretty much the amount of information/data that gets sent (i think?), and the more IN you have the more you/the server will lag.
    IN is heavily influenced by the engine doing complex/dynamic stuff. Like if you have a model with 35 bone followers moving around, the engine will need to check all the "followers" for every bone yaddiyaddiyadda, and it will lag pretty badly. A fix for this model issue would be to disable bone followers or remove the .PHY file for that exact model (which would decrease the IN by far, far, far, though it would remove collision).
    IN will also be influenced highly by alot of players standing on the same prop, and especially if it has a whole lot of collision parts, even more if it's dynamic too. My trusty lagevator is a perfect example for this, as the IN goes super high/the server almost dies if all players get zombiefied inside the elevator while being on fire, at the same time as everyone stands on a moving+dynamic prop while hugging the prop_static wall with lots of collision parts. It's just a mishmash of disaster and i do apologize for it, so do yourself a favor and don't do like i did it.

    You also have some more basic limits, like the brush/plane/water indices limit.
    These limits are as mentioned.. pretty damn basic. If you add way too many brushes you'll probably get a plane limit error, causing the compiler to abort.
    You can easily fix this by using a wonderful little program called "Propper" which makes props out of your brushwork, though be sure to take it easy on the collision parts.

    I've probably skipped through something really important and/or gotten something horribly wrong, so feel free to correct my wrongness if needed.
    And finally, remember that premature optimization is bad for you. Just make whatever you want to make, follow your dreams! If something goes wrong in the future there's always room for change/improvement.
    Don't be super picky like i am, do stuff and you'll actually get stuff done. That's my personal advice for today.

    Wall of text, for all the wins!
    • Informative Informative x 3
    • Mapping King Mapping King x 2
    • Agree Agree x 1
    • Zing! Zing! x 1
    • May 31, 2012
      Although the edict limit is 2048, you shouldn't go past 1408 since players eat up multiple edicts and, for ease, we assume 10 edicts/player. It'd be safer to stay at 1200, though.

      For the .bsp format limits, and if you feel like reading code that really serves no purpose whatsoever while mapping (almost always) you have http://www.bagthorpe.org/bob/cofrdrbob/bspformat.html.

      When you compile a map, in the console log you get something like:

      Object names	  Objects/Maxobjs  Memory / Maxmem  Fullness
      ------------	  ---------------  ---------------  --------
      models				493/1024		23664/49152	(48.1%)
      brushes			  4998/8192		59976/98304	(61.0%)
      brushsides		  45276/65536	  362208/524288  (69.1%)
      planes			  56894/65536	1137880/1310720  (86.8%) VERY FULL!
      vertexes			43322/65536	  519864/786432  (66.1%)
      nodes				12038/65536	  385216/2097152  (18.4%)
      texinfos			  8140/12288	  586080/884736  (66.2%)
      texdata				84/2048		2688/65536	( 4.1%)
      dispinfos				3/0			528/0		( 0.0%)
      disp_verts			243/0			4860/0		( 0.0%)
      disp_tris			  384/0			768/0		( 0.0%)
      disp_lmsamples	  16848/0		  16848/0		( 0.0%)
      faces				23975/65536	1342600/3670016  (36.6%)
      hdr faces			23975/65536	1342600/3670016  (36.6%)
      origfaces			17507/65536	  980392/3670016  (26.7%)
      leaves			  12532/65536	  401024/2097152  (19.1%)
      leaffaces			29138/65536	  58276/131072  (44.5%)
      leafbrushes		  11351/65536	  22702/131072  (17.3%)
      areas					4/256			32/2048	( 1.6%)
      surfedges		  183396/512000	733584/2048000  (35.8%)
      edges			  112039/256000	448156/1024000  (43.8%)
      LDR worldlights		249/8192		21912/720896  ( 3.0%)
      HDR worldlights		249/8192		21912/720896  ( 3.0%)
      leafwaterdata			8/32768		  96/393216  ( 0.0%)
      waterstrips		  2185/32768	  21850/327680  ( 6.7%)
      waterverts			  0/65536		  0/786432  ( 0.0%)
      waterindices		37344/65536	  74688/131072  (57.0%)
      cubemapsamples		  0/1024			0/16384	( 0.0%)
      overlays				11/512		  3872/180224  ( 2.1%)
      LDR lightdata		[variable]	7186760/0		( 0.0%)
      HDR lightdata		[variable]	7186760/0		( 0.0%)
      visdata			  [variable]	  950620/16777216 ( 5.7%)
      entdata			  [variable]	  439493/393216  (111.8%) VERY FULL!
      LDR ambient table	12532/65536	  50128/262144  (19.1%)
      HDR ambient table	12532/65536	  50128/262144  (19.1%)
      LDR leaf ambient	47089/65536	1318492/1835008  (71.9%)
      HDR leaf ambient	46852/65536	1311856/1835008  (71.5%)
      occluders				0/0			  0/0		( 0.0%)
      occluder polygons		0/0			  0/0		( 0.0%)
      occluder vert ind		0/0			  0/0		( 0.0%)
      detail props		  [variable]		  1/12	  ( 8.3%)
      static props		  [variable]		  1/12	  ( 8.3%)
      pakfile			  [variable]	  166537/0		( 0.0%)
      physics			  [variable]	1997938/4194304  (47.6%)
      physics terrain	  [variable]		833/1048576  ( 0.1%) 
      Explaining all of these stuffed stuff would be too much, but in general (the three last row-values X/Y (Z%) are current/maximum (percent%)):

      1. Models refers to brush models, as in triggers and func_ entities. There is a limit of 1024, so you'd have a maximum of brush entities defined by this. However, you'd rarely hit this limit since most of the times you have to use networked point entities and logic entities.
      2. Brushes, brushsides, planes, faces and vertexes refer more or less to what their names mean. Brush sides is better defined in the .bsp format specs I linked; plane is there too. As I'm a trainwreck of a person I'll avoid trying to give a pompous explanation since I'd probably look like a fucktard.
      3. Visdata contains all the visibility nodes of the .bsp tree. Paper is optimized like crap and you can see a 5.7% only, so unless you're wrecking shit real bad I don't see how you'd reach this.
      4. LDR and HDR tables are lighting tables. If you go past these limits, VRAD won't compile. Increasing the lightgrid size in Hammer helps (use powers of two, the higher the number the lower the quality of the lightmap, the lower the size).
      5. Entdata doesn't matter. I've reached 200% at times and Luff reached more than that, I believe. Source will keep allocating memory for it.
      • Informative Informative x 1
      • Jul 20, 2012
        Interesting. I'm going through Tophattwaffle's guides and doing my personal touch on them in Hammer, and learning by doing curious mistakes. The different entities that one can program would be the hardest part to learn. There seems so much one could do with it, but making a too complex game would easily go beyond the limits. I sure would like to learn, but I have to take it step by step, and it takes forever to go through. I've been playing CS(S) and ZE for so long it's interesting to learn and see how a map is made up, so I just had to check it out. Thank you all for your answers, even though a beginner like myself struggles to understand some of the stuff, but I'm getting there slowly :smile:
      • Apr 9, 2012
        To lighten 2 more:

        Static props are limited to 4096 at once. LeGrem once told me this xD I believe he once reached this on one of the first ze_Jurrasic_Parc_story versions.

        waterindices 37344/65536 74688/131072 (57.0%)ieve he

        This, has nothing to do with water. This has to do with T-junctions such as func_details touching each other or world brushes touching each other (I'm not sure but I think detail to world brush do not create a T-junction, it only works within the details themselves and world brushes themselves, though I should test this specifically for clearance).

        In other words, when you are having 2 detail brushes touching each other face to face, the engine will merge those together and calculate the polygons/vertices that way. This also happens in modelling, though you can also just have objects get into each other and specifically select them not to do this, but turns in modelling against your favour so I guess the T-junctions come from this same specific reason.

        The detail brushes can also intersect with each other, and then during compile these will be merged together. Waterindices also happens when you have an empty sealed room (textured or not) but there is literally nothing in it, not even a point entity like info_target, because during compile this room will be filled so that no VISleafs are being put in for no reason, as because there is no acces to the room there is no reason for the compile to use that space.
        JorisCeoen, Dec 3, 2013 Last edited by JorisCeoen, Dec 3, 2013
      • May 31, 2012
        I've had test maps with up to 6720 static props. The limit, from what I've read, is 8192.

        Pic related. A jungle.
      • Apr 9, 2012
        Wow that is much more than I always thought :O Ok that's good to know xD however if someone would ever reach this count they should seriously consider modeling to group some stuff together xD
      • Jan 11, 2011
        Pretty much what you had been told already by @Luffaren, @enviolinador and @JorisCeoen.
        When Paranoid got changed using Propper on it for the first time I hit the Static Limit (because every pillar and every side of each "labyrinth block" was a prop on their own; since the engine prefers repeating simple small props that having big ones), but it was too much (I never remember if 4096 or 8192, but I would trust Enviolinador since he gave an example map) and had to group many props together (into the "Labyrinth Blocks").
        However, is very rare to reach the Static Prop limitation.

        The limitations that you more frequently will encounter, and how to avoid them are as follow:

        - Grid size: A pretty obvious one that doesn't need explanation.
        Solution: Don't make brushes that crossing or touch the Hammer Grid Limits. Anyway, if you do, the map won't compile.

        - Brush Faces/Planes/Vertex: This occurs when you have too many brushes (easy to happen on a big map like Minas Tirith) or abuse "complex" brushwork (like Spheres, Cilinders, etc). This is specially noticeable and easy to reach if you do circular creations (a coliseum or Paranoid's Core) or if you abuse circular/cilindric constructions, like lots of cilindric stone pillars.
        Solution: Try to keep all your cilindres/spheres/detailed brush work as models. Propper usually helps with this, but I had word that isn't working after the last update. Not sure about that.

        - Displacement, Prop_Static...: Everything in Hammer has a limit; but somethings have their own specific limits, like those 2 examples. Reaching the Static's limit is very hard and arguably impossible unless you start copy-pasting constructions of many statics (like I did with the Paranoid Labyrinth Blocks) or spamming lots and lots of things (like trees and plants to make a huge forest). Displacements on the other hand... even if its still a pretty high limit that you usually don't have to worry about, you can easily reach it if your whole map is based around displacements (I believe Freeze hit it with ZE PotC and had to reduce/remove some of them).
        Solution: If you hit the Prop Static limit, you will have to remove prop statics and/or transform some (modeling programs, not hammer) from being individual props (like 8 pillars and 4 walls) to a single prop (a Paranoid Labyrinth Block).
        If you hit the Displacement limit, try reducing them to a lower value (from 3 to 2 for example), or remove 4 displacements and replace them with a single one; in both scenarios you will lose quality. You can make props out of displacements; but those won't be solid (so only use them for areas that players won't be able to reach) and will receive mediocre shadows at best, usually none (like the rotating displacement props on the skybox of ZE UT2004 Convoy).

        - Light Map Grid: Think about this limitation as a huge texture that gets made when you compile your map with RAD (radiosity: lights/shadows). When the map compiles, it creates this "huge texture" that is only "shadow ON/OFF" and gets placed all over the entire surface of your map. In a very big or detailed map, you will reach this limit and the RAD won't compile (and the map will show as Full Bright). Also notice, that this can increase the map size by a lot, specially if its a non complex map with huge surface (think about a big open field, the map could go from 3 MBs to 60 MBs from having RAD or not).
        Solution: For both reducing the map size and going under the limitation (in order for light/shadows to work) you will have to increase the Light Map Grid on some textures (or all of them). Always use the default power of 2 that Hammer loves so much. So 4, 8, 16, 32, 64... The higher the number, the lower the resolution and size of the "shadow texture". (Think of it about it being the size of each "Shadow Pixel", so 64x64 shadow pixels have less resolution than 32x32 pixels; and they are 4 times smaller). Is usually wise using high numbers on surfaces that don't receive shadows at all, or that are (for example) pitch black. (Note that using "Tools/Black" will automatically ignore the Light Map Grid on that surface).

        - Entities: Or how I like to refer to them "Dynamic Entities". As Luffaren has already mentioned, only certain entities count towards this limit. Those are generally the "dynamic ones" that can change. For example, a Prop_Dynamic can have animations, can be killed, can be parented, can have a RGB value... hence its a dynamic entity. A Prop Static can't, and will always remain the same for everyone on the server, so its a static entity that "lives in the map", instead of being one that can change and has to been tracked by the server to make sure that everyone sees it ON/OFF/Whatever.
        As a rule of thumb, most entities are dynamic, with the most common exceptions of: Prop_Static, Prop_Detail, Func_Detail, Unnamed Lights and Decals. Those are all entities that don't count towards the "Dynamic Entity Limit" and have their own limits. (Something like 4-8K for Statics, 8-32K for Details, never reached lights or decals but probably 2-4Ks).
        EDIT: Apparently Decals and Overlays do count towards this limit when the map spawns (loads) for the first time?
        Take note that we specify "Unnamed Lights" because as soon as you name a Light, it can be turned ON/OFF by a button/trigger/event, and even if its never getting changed or parented, it will start counting as a Dynamic Entity. (Lights with glares automatically count as dynamic entities as the glare itself is a dynamic entity).
        Solution: As long as you don't waste entities stupidly, and stay away from detailing with lots of entities (glares, fires, smokes, breakables, dynamics) you should be pretty safe. Entities can be a nightmare if you are trying to do something huge and/or with lots of needed entities for its functionality (like Paranoid having lots of special items/weapons; Minas Tirith having lots of barricades/soldiers, or the upcoming Luffaren ZE map having lots of stages and events), but usually, as long as you know what you are doing, they are easy to keep at bay.
        (Remember that the Bone Followers of the Prop Dynamics count each as 1 entity, so if you don't really need them (you usually don't) disable them, as it saves tons of entities and IN).
        PD: As Enviolinador said, disregard the "Ent Data" shown in the compile log, as its just a guideline, but a very bad one; since it counts things that don't count towards the Dynamic Entity limit (like Lights).

        - IN: Not itself a Hammer limit, but something that will lag (and it can even crash) the servers. Think about IN as the information that needs to be passed from the server to the players to make sure everyone is seeing the same things. So... When the Bridge in Mako Reactor starts falling, the server has to keep sending information to all the players about where the bridge is so everyone sees it at the same place. Same goes, for example, for the triggers/entities/models parented to special weapons/monsters, or even a light that can be turned ON or OFF. Almost all the Dynamic Entities previously mentioned. The thing is... Most of those things generate such a small amount of IN that its unnoticeable. What really generates noticeable amounts of IN are the Bone Followers of the Dynamic Objects and the Physic in general.
        Solution: Disable the Bone Followers of your Dynamic Objects (this will make them non-solid; so deal with it; cover them with a solid invisible brush that is way simpler; or try to keep the map from having more than 1 of those objects loaded at once) and don't abuse the physic objects. With Net_Graph 1 you can see the IN in singleplayer. Try to keep it under 300. 350-400 may start lagging some servers that don't have really good connection or have lots of players of them (since you kinda have to multiply IN x Players to get the real information being send).

        - T-Junctions: This was right now the one that was giving me the most problems on Junon while trying to do fast compiles (without things being props yet nor everything optimized). It happens mostly when Func_Details touch World Geometry or other Func_Details, and it appears to increase when you are using big/huge brushes for both of those.
        Solution: Change some Func_Details into Models or make the Old HL1 Trick of making the Func_Details NOT touch the World Geometry (keeping them 1 Hammer Unit away; like the bottom and top of lots of pillars in a room). But usually you won't encounter this limit unless you are doing something huge.

        - Time and Player Limits: This goes without saying, but just remember that the maximum number of players or minutes that CS:S can handle without plugins is 9 minutes and 64 players. Some servers can increase those with plugins or workarounds, but don't count on them if you want to see your map in as many servers as possible. Also, try to keep at least 1 extra minute over the time it takes to complete the map (so players can fool around a little or just don't have to do everything on a perfect timer), so never make a map that takes more than 8 minutes to complete (but I would say 5-7 minutes is usually better for ZE rounds). Also, don't fall into the "Singleplayer Mapping Syndrome" of making the map while thinking/comparing/testing it only on singleplayer, or you may end with maps too small/claustrophobic (in a bad sense) for when 40 humans are holding 20 zombies. Examples of this would be some corridors at Paper Escaper (but it helps that there are many corridors to choose from early on, and some open areas) and specially ZE_Saw.
        Solution: Just remember those limits and take them into account.

        - BSP Size: There is an actual BSP size limit. I don't remember if it was 512 or 1024 MBs... But anyway, your map will be "unplayable" way before that. Not only it will take long to load on older computers; but many servers won't get a 300 MBs map on rotation, forcing everyone trying to join to download it (and sometimes making them lose players that just go "screw this download" and go to other server or do something else). Some maps get away with huge sizes because they are really popular and they have excuses for it (being huge maps on their own, and having tons of extra content like music/models/etc); but still then only if they are good maps will be put on rotation. A mediocre/bad map with huge size? They won't even think about it.
        Lately with better connections and maps like Skyrim (and its tons of versions) people got used to downloading bigger maps; but still, try to keep it at small as possible. Sometimes adding extra textures/resolution is just not worth it.
        Solution: Keep the BSP size as small as possible. You don't need to sacrifice big things (like that Dragon model or that cool music); just make sure you don't add more than necessary or that those things that you add (like those 2 examples) aren't way bigger than they should (like the Dragon having 4096x4096 textures instead of 1024x1024 when they look the same on Source; or the music being a 40 MBs .wav instead of a 4 MB .mp3). Also, don't just add for adding... I have seen some maps that include 50 MBs of custom textures that make them look worse than the same map would only using the default ones in the correct way.

        - FPS: Again, not a real "Hammer Limit" but something that needs to be taken into account very seriously. Try to divide your map into areas that don't see each other; even if its an open map. There are cheap ways of solving this (like using the Z Clip Limit (rendering distance for players; usually masked with fog, like on ZE Lost World Redux) but usually you won't need it with smart mapping, dividing the map in areas and taking into account what places you can see from everywhere and how to reduce it if necessary.
        Solution: Remember that FPS are also a limit of sorts, as with very bad FPS your map could get removed from rotation; so try to map smartly taking FPS and view distances/areas into account.

        Its very common for some new mappers that are talented in other creative fields (mapping for different games, drawing, modeling, etc) to think "I'm going to make the best CS:S map, it will be huge, like a real city, super detailed, with lots of breakable/dynamic stuff like those new games, NPCs, etc", but there is a reason such map don't exist on Source, and trust me is not because the lack of talented mappers.
        But to be honest, for a long time now, with all the tricks we are learning/passing/teaching to each other, we have yet to figure out the real limitations of hammer. As with Propper, Smart Entity Use, Creative Templates and Output Lines, etc, etc... We are beating those limits more and more.
        I would like Luffaren to finish his ZE secret project to see how it ends (because he is trying to do something huge). But on his case, since limits to Light Map Grid and Displacements exist (things that he needs/uses a lot), the visuals get really affected by it.
        • Informative Informative x 2
        • Like Like x 1
        • Useful Useful x 1
          Kaemon, Dec 3, 2013 Last edited by Kaemon, Dec 3, 2013
        • Feb 21, 2007
          A statue of retslag1 is necessary, as well.
          • Agree Agree x 2
          • Funny Funny x 2
          • Good Idea Good Idea x 1
          • Feb 27, 2012
            Some day, retslag.... some day.
            • Winner Winner x 1
            • Feb 3, 2012
              Tony promised. :<
              • Winner Winner x 1
              • Feb 24, 2011
                Just give me something to base it on, and i should be able to work some personal (most likely bad) magic in blender!
                Would you prefer your trousers golden, silver or pink?
                It just might happen, no promises though!
                • Winner Winner x 1
                • Feb 21, 2007
                  Silver. House and Gman are a good place to start! :smile:
                • Jun 11, 2012
                  We demand nude model of yourself for base to draw upon
                  • Agree Agree x 1
                  • Jan 12, 2011
                    Why not split the difference? House's head on Gman's body, and call it GHouse. Admittedly, the face isn't too different, just a bit more specific.

                    Going along with GHouse, I can only imagine it turning out into something like this:

                    michelangelo Knowledge Spark color

                    Who should "God" be? Idk, stick Brian's cat in there or something.

                    Also, I must say that my mind is blown with the amount of mapping information in here. I know there's a resource section available to look at, but wow. I adore all these text walls. I may not know what most of them mean or are supposed to reference beyond general context, but just wow. Props to all of you mapping encyclopedias. :nerd:

                    Edit: And no pun intended on that last statement. Derp :razz:
                    Vadleon, Dec 3, 2013 Last edited by Vadleon, Dec 3, 2013
                  • Dec 30, 2006
                    I thought we agreed a few months back that all maps will require a statue of rets somewhere on the map. What's the status of this? You stated that you would do it and I have yet to see a statue arise.

                    Tis a shame. :neutral:
                  • Feb 27, 2012
                    Well i guess he already has a statue. Well, multiple sizes. It's on that mg_warmcup_headshot map... You know, on that pretty pink course :wink: