Cliptype -precise Doubles .bsp Size?
Heist
Join Date: 2002-11-09 Member: 7922Members
Join Date: 2002-11-09 Member: 7922Members
<div class="IPBDescription">BIG PROBLEM</div> Well... I was zipping up my latest compile of ns_trane when I saw that my .bsp file is now 12MB! It has doubled since my last beta version and I have not added nearly that much. The only thing I can attribute to this is that I had to use XP-Cagey's compiler(with -cliptype precise). Is anyone else having this problem?
Comments
Would you mind doing a hlrad execution with -chart specified to see what is taking up the memory? I'd actually be suprized to see 6MB of additional information just for precise clip hulls. It's possible to spike the compile size by doing a full vis or using a smaller chop size, but it could just be that the more accurate clipping is taking up more room. The second-to-right chart column (next to the percentages) gives memory usage in bytes, and I'm curious to see what's taking up the majority of the size.
You may want to see what happens with the simple clip type, which ought to reduce the complexity of the map again.
------------ --------------- --------------- --------
models 196/400 12544/25600 (49.0%)
planes 24976/65535 499520/1310700 (38.1%)
vertexes 33864/65535 406368/786420 (51.7%)
nodes 13067/32767 313608/786408 (39.9%)
texinfos 3283/32767 131320/1310680 (10.0%)
faces 24794/65535 495880/1310700 (37.8%)
clipnodes 30224/32767 241792/262136 (92.2%)
leaves 8163/8192 228564/229376 (99.6%)
marksurfaces 32693/65535 65386/131070 (49.9%)
surfedges 117175/512000 468700/2048000 (22.9%)
edges 59256/256000 237024/1024000 (23.1%)
texdata [variable] 4037040/4194304 (96.3%)
lightdata [variable] 5198316/6291456 (82.6%)
visdata [variable] 447620/2097152 (21.3%)
entdata [variable] 68731/524288 (13.1%)
I'll try compiling using simple tonight.
------------ --------------- --------------- --------
models 196/400 12544/25600 (49.0%)
planes 24976/65535 499520/1310700 (38.1%)
vertexes 33864/65535 406368/786420 (51.7%)
nodes 13067/32767 313608/786408 (39.9%)
texinfos 3283/32767 131320/1310680 (10.0%)
faces 24794/65535 495880/1310700 (37.8%)
clipnodes 30224/32767 241792/262136 (92.2%)
leaves 8163/8192 228564/229376 (99.6%)
marksurfaces 32693/65535 65386/131070 (49.9%)
surfedges 117175/512000 468700/2048000 (22.9%)
edges 59256/256000 237024/1024000 (23.1%)
<span style='color:white'>texdata [variable] 4037040/4194304 (96.3%)
lightdata [variable] 5198316/6291456 (82.6%)</span> [emphasis added in reply]
visdata [variable] 447620/2097152 (21.3%)
entdata [variable] 68731/524288 (13.1%)
I'll try compiling using simple tonight.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Translating the memory numbers to KB/MB:
models: 12.3 K
planes: 487.8 K
vertexes: 396.8 K
nodes: 306.3 K
texinfos: 128.2 K
faces: 484.3 K
clipnodes: 236.1 K
leaves: 223.2 K
marksurfaces: 63.9K
surfedges: 457.7 K
edges: 231.5 K
<span style='color:white'>texdata: 3.85 MB
lightdata: 4.96 MB</span>
visdata: 437 K
entdata: 67.1 K
The main culprit seems to be your light and tex data, which combined are 8.80 MB -- texdata is used to store texture information (-wadinclude), and light data is generated by hlrad, and isn't affected by the unlit clip hulls... have you changed your hlrad settings? Older builds of the tools would cause a buffer overflow when lightdata exceeded 4 MB, which may also be affecting the final state of the BSP.
EDIT: It's a drop in the bucket, but if you use opt_plns, it'll probably knock your planes down about 60%, freeing up a few hundred K of memory.
EDIT (again): My apologies, texdata is texture information... entdata is the text for entity key/value pairs. I have no idea what I was thinking what I wrote it the other way around... guess I need to get some sleep.
leaves 8163/8192 228564/229376 (99.6%)
Texdata....
Jeah in your case "precise" takes you to the limits.
btw. precise is not "the ultimate thing" just to say its not essential and it can cause some "in void seeing" on stairs.
If simple gives you 30-10% less clipnodes and you dont have a sticky feling just use that.
You added some small stuff, even that small stuff can increase clipnodes rapidly.
Averagely every new Plane/(Face) in a room (e.g. of a computer terminal) gives one or more new clipnode(s).
turning stuff into func_walls, especially stuff with many faces, pipes and big room-central objects, decreases your clipnodes.
Another way decreasing clipnodes is wise usage of clip brushes (wohoo) and turning "furniture stuff" into models.
This is from my previous Beta.
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 172/400 11008/25600 (43.0%)
planes 23780/32767 475600/655340 (72.6%)
vertexes 32822/65535 393864/786420 (50.1%)
nodes 12634/32767 303216/786408 (38.6%)
texinfos 3166/32767 126640/1310680 ( 9.7%)
faces 24024/65535 480480/1310700 (36.7%)
clipnodes 32417/32767 259336/262136 (98.9%)
leaves 7841/8192 219548/229376 (95.7%)
marksurfaces 31706/65535 63412/131070 (48.4%)
surfedges 113605/512000 454420/2048000 (22.2%)
edges 57465/256000 229860/1024000 (22.4%)
texdata [variable] 444872/4194304 (10.6%)
lightdata [variable] 2679426/4194304 (63.9%)
visdata [variable] 433814/2097152 (20.7%)
entdata [variable] 58570/524288 (11.2%)
Can someone tell me how adding 4 particle systems and a few lights can jump the tex data up over 3 and 4 megs respectively?
They cant!
Texdata is just the magical 4 mb limit of used .wads , no matter what compile settings you use (*) this just depends on the ammount of used textures.
not more.
*-> Ignoring -wadinclude (stores textures in the .bsp and not in a .wad) and -texdata (increase the limit but it wont run in software mode anymore)
just use less different or smaller textures from your .wads
They cant!
Texdata is just the magical 4 mb limit of used .wads , no matter what compile settings you use (*) this just depends on the ammount of used textures.
not more.
*-> Ignoring -wadinclude (stores textures in the .bsp and not in a .wad) and -texdata (increase the limit but it wont run in software mode anymore)
just use less different or smaller textures from your .wads<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Ollj is correct and I misspoke (badly) above -- the texdata amount is the total amount of texture data on the map, which will include raw image data in uncompressed format if you use a -wadinclude in your compiles. I'm speculating that the 12MB build had some extra textures bundled directly into the map.
If the particle systems don't cast any light (and I don't think that's an option), the lightdata jump is due to the lights you've added.
Adding even a few lights can cause a huge jump in lightdata if the lights aren't static (unnamed and without any sort of flicker setting). I talk about that in <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=22914&hl=lightdata' target='_blank'>this thread</a>. KungFuSquirrel gives a story of a single flickering light killing his map in <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=21930&hl=lightdata' target='_blank'>this thread</a>.
Don't know what I was thinking. Thanks for your help.