Ignore the first number before each forward slash, these stats were taken from a compile log (which every map you compile gives out) and it tells you what percentage of the max your map uses out of the Source engine. note: this map was compiled for HL2DM, I've never compared the maxes from other games.
Object names Objects/Maxobjs Memory / Maxmem Fullness ------------ --------------- --------------- -------- models 52/1024 2496/49152 ( 5.1%) brushes 1874/8192 22488/98304 (22.9%) brushsides 14727/65536 117816/524288 (22.5%) planes 12380/65536 247600/1310720 (18.9%) vertexes 12030/65536 144360/786432 (18.4%) nodes 2236/65536 71552/2097152 ( 3.4%) texinfos 2829/12288 203688/884736 (23.0%) texdata 47/2048 1504/65536 ( 2.3%) dispinfos 145/0 25520/0 ( 0.0%) disp_verts 3625/0 72500/0 ( 0.0%) disp_tris 4640/0 9280/0 ( 0.0%) disp_lmsamples 261532/0 261532/0 ( 0.0%) faces 4836/65536 270816/3670016 ( 7.4%) hdr faces 0/65536 0/3670016 ( 0.0%) origfaces 4318/65536 241808/3670016 ( 6.6%) leaves 2289/65536 73248/2097152 ( 3.5%) leaffaces 6451/65536 12902/131072 ( 9.8%) leafbrushes 4040/65536 8080/131072 ( 6.2%) areas 4/256 32/2048 ( 1.6%) surfedges 41170/512000 164680/2048000 ( 8.0%) edges 27160/256000 108640/1024000 (10.6%) LDR worldlights 81/8192 7128/720896 ( 1.0%) HDR worldlights 0/8192 0/720896 ( 0.0%) waterstrips 603/32768 6030/327680 ( 1.8%) waterverts 0/65536 0/786432 ( 0.0%) waterindices 10743/65536 21486/131072 (16.4%) cubemapsamples 47/1024 752/16384 ( 4.6%) overlays 32/512 11264/180224 ( 6.3%) LDR lightdata [variable] 2026976/0 ( 0.0%) HDR lightdata [variable] 0/0 ( 0.0%) visdata [variable] 135217/16777216 ( 0.8%) entdata [variable] 209380/393216 (53.2%) LDR leaf ambient 2289/65536 54936/1572864 ( 3.5%) HDR leaf ambient 0/65536 0/1572864 ( 0.0%) detail props [variable] 1/12 ( 8.3%) static props [variable] 1/10730 ( 0.0%) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tom Schumann Sent: Thursday, May 28, 2009 3:11 AM To: Discussion of Half-Life Mapping Subject: Re: [hlmappers] Source Engine/Hammer Size maximum size Have a look in sourcesdk.gcf\src_mod\orangebox\public\bspfile.h It lists most of the limits. #define MAX_MAP_ENTITIES 8192 might be what you're looking for, but I'm not sure. 2009/5/28 Phillip Marshall <[email protected]> > Even if you could make an outrageously huge map, you might not really want > to. > > Think of it this way: If you could fit all five of Left 4 Dead's No > Mercy campaign maps into one, you would have to endure five times the > compile time, five times the memory load in Hammer - an application > which can be unstable enough as it is, five times the loading time > in-game, five times time the memory load in-game to the end user (who > might have a minimum spec machine that you have to consider), and five > times the server load on a multiplayer map. This isn't even > considering that some aspects of this (like compile time maybe, I > don't know for sure) might multiply exponentially with size. So > basically, if you were to attempt to create anything up to Valve's > professional standards (think of Half-Life 2's levels that wind around > each other and overlap - Ravenholm for example - all the while > including tons of detail and gameplay), you are honestly better off > making a series of small, detail rich maps than making giant ones that > hold everything at once. > > Then again, you could be wanting to make giant open maps just to screw > around and play in (like flatgrass in Garry's Mod), which would be > fine depending on what you want to put in the map. Just consider this > before rushing off to make the Left 4 Dead equivalent of the Empire > State Building. > > Maybe I should actually help answer the question: > I would imagine the absolute maximum size of any brush or level would > be the bounding box of the 2d views in hammer - if you zoom out all > the way, the grid only goes so far. I don't know if you can draw > outside of those though, I've never tried. > > Thanks for listening to me ramble, I guess. Good luck on your map, > whatever it may turn out to be. > > Phillip Marshall > AKA wizpig64 > > On Wed, May 27, 2009 at 11:43 PM, Alex Guichet <[email protected]> wrote: > > > > Does anyone know or have any data on the maximums or minimums of hammer > and > > the source engine for mapping. I'm not looking for "realistic" values by > any > > means. Such things like "Is it possible to have a brush with the unit > size > > of 1.0x10-99" (Which is unreasonably small if you're wondering.) > > Basically most important data I need is: > > > > Maximum # of entities > > Maximum total size of map (area and/or X*Y*Z values) > > > > and any other maximum or minimum that has to do with hammer or the source > > engine that you might think is important. > > > > And if you are aware of any hammer related limitation that the source > engine > > can exceed LET ME KNOW. *Engine values and numbers have priority over > > hammer's limits.* > > > > > > I know this seems random, but I'm starting a new project.... you'll find > out > > more about it in the future. > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlmappers > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlmappers > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlmappers _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlmappers
