Yet another of my help threads to spam the mapping section. SORRY GUYS!
Well my map is about 1 third of the size of the biggest maps I know that aren't just flat area. eg. Evocity2
And yet I have appeared to hit my vertex/entities limit. I have been told there is no way to heighten the limit so I'm sort of stuck and have a few questions.
1) Does making a brush func_detail take away from the vertexes?
2) I need some tips on lowering my entities while still making my map function.
My goal was to make an RP map with lots of things to do, lots of functionality.
I'm not so sure that's possible anymore.
I'm afraid whats eating up my limit is my lighting.
It seems the more I try to make it look nicer for all those picky dicks out there the more lights I have all together.
Well help would be appreciated, tips, whatever I can get.
Group brushes together and tie them to a func_detail to lower the entity count (If you havn't done so already)
Will this help my vertex limit too?
I don't believe so. If you have a lot of brush-based models, consider making them actual models to save you vertices.
Well I think it did reduce my vertexes, I did a compile and found that the percentage was lowered, though my entities didn't lower much, still at very full.
[editline]09:18PM[/editline]
Here, if it helps. The limits part of my compile log.
[code]Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 232/1024 11136/49152 (22.7%)
brushes 6331/8192 75972/98304 (77.3%)
brushsides 47199/65536 377592/524288 (72.0%)
planes 23642/65536 472840/1310720 (36.1%)
vertexes 48962/65536 587544/786432 (74.7%)
nodes 17023/65536 544736/2097152 (26.0%)
texinfos 7463/12288 537336/884736 (60.7%)
texdata 912/2048 29184/65536 (44.5%)
dispinfos 362/0 63712/0 ( 0.0%)
disp_verts 39514/0 790280/0 ( 0.0%)
disp_tris 65152/0 130304/0 ( 0.0%)
disp_lmsamples 1186620/0 1186620/0 ( 0.0%)
faces 27907/65536 1562792/3670016 (42.6%)
hdr faces 0/65536 0/3670016 ( 0.0%)
origfaces 18233/65536 1021048/3670016 (27.8%)
leaves 17256/65536 552192/2097152 (26.3%)
leaffaces 34361/65536 68722/131072 (52.4%)
leafbrushes 13136/65536 26272/131072 (20.0%)
areas 4/256 32/2048 ( 1.6%)
surfedges 210966/512000 843864/2048000 (41.2%)
edges 131256/256000 525024/1024000 (51.3%)
LDR worldlights 425/8192 37400/720896 ( 5.2%)
HDR worldlights 0/8192 0/720896 ( 0.0%)
waterstrips 3171/32768 31710/327680 ( 9.7%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 57786/65536 115572/131072 (88.2%) VERY FULL!
cubemapsamples 53/1024 848/16384 ( 5.2%)
overlays 129/512 45408/180224 (25.2%)
LDR lightdata [variable] 21705440/0 ( 0.0%)
HDR lightdata [variable] 0/0 ( 0.0%)
visdata [variable] 0/16777216 ( 0.0%)
entdata [variable] 376647/393216 (95.8%) VERY FULL!
LDR leaf ambient 17256/65536 414144/1572864 (26.3%)
HDR leaf ambient 0/65536 0/1572864 ( 0.0%)
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/56838 ( 0.0%)
pakfile [variable] 784381/0 ( 0.0%)
Level flags = 0
Win32 Specific Data:
physics [variable] 2408723/4194304 (57.4%)
==== Total Win32 BSP file data space used: 35327477 bytes ====[/code]
The water indices don't bother me
func_detail doesn't get rid of verts simply by being one, but if deattaching it from merging with the world it rests next to means there is less vertices made, that's why it would make less verts.
Also I would be concerned with the indices, an index tells which 3 verts make up a triangle (although source uses methods so that not every triangle needs an index, although average levels need them a lot). max them and you've had it, there's nothing you can do. For some reason, source puts the entire level into one vertex buffer and one index buffer (at the size of an unsigned int), but that's probably just because it's old and they haven't yet changed it. Personally I think it's a bit weird for them to not have upped it much earlier.
[QUOTE=Pj The Dj;16131710]func_detail doesn't get rid of verts simply by being one, but if deattaching it from merging with the world it rests next to means there is less vertices made, that's why it would make less verts.
Also I would be concerned with the indices, an index tells which 3 verts make up a triangle (although source uses methods so that not every triangle needs an index, although average levels need them a lot). max them and you've had it, there's nothing you can do. For some reason, source puts the entire level into one vertex buffer and one index buffer (at the size of an unsigned int), but that's probably just because it's old and they haven't yet changed it. Personally I think it's a bit weird for them to not have upped it much earlier.[/QUOTE]
Thanks for the info. As the entity limit seems to not go on number but memory, is there certain entities I should avoid or try and get rid of to bring it down? I have ALOT of lights, but I'm not sure if that's just normal.
If I remember correctly, the limits are just warnings, if you go over it just adds a lot more space to the map and it's a lot more laggy, I'm probably wrong though, you shouldn't trust me :)
[QUOTE=yisurhp0;16134317]If I remember correctly, the limits are just warnings, if you go over it just adds a lot more space to the map and it's a lot more laggy, I'm probably wrong though, you shouldn't trust me :)[/QUOTE]
I'm pretty sure that's just entdata. IIRC, someone got to about 200% before it started having issues.
Well that's good to know
Sorry, you need to Log In to post a reply to this thread.
