Page 3 of 3

Re: MAX_MAP_DRAW_INDEXES

Posted: Fri Jul 20, 2012 2:47 am
by RedSnappa
The trisoup is 128x128 for the most part. I use FS_q3map_Radbump_4a.
arctica18.jpg

Re: MAX_MAP_DRAW_INDEXES

Posted: Fri Jul 20, 2012 3:04 am
by vulture
Well that accounts for about 4k brushes. Do you have any curved surfaces? If you use too many subdivisions on those, they can easily cost you a lot of brushes. If I had to guess though, I'd just say it's because of your one large open area with lots of non-coplanar brushes. I'm not sure if there's a brush option to make that any better for your terrain, but I'd imagine a patch mesh would be more efficient at storing the terrain internally.

The Radbump_4a is based on super old code (as far as I could tell) that is less efficient and less precise at optimizing stuff. I've reduced the size of my bsp's by as much as 50% by using Rambetter's q3map2 patched with the experimental math stuff. When I decompile compiled bsps that were based on old code, I would see vertices that had like 17.001 instead of 17.000 all over, for all dimensions on many brushes. Newer q3map2's are more precise and also as a result, you also save space because you don't need to store these slightly offset coordinates. You lose the bumpy aspect, but you might save a ton of bsp space by using one of the upgraded q3map2's.

As for my suggestion, I recommend you make a backup of your .map, then remove large sections of your map one step at a time, recompile, and test to see if you've saved any space. When you find some big thing, I guess you've found your problem. :P My first recommendation would be to try removing all your terrain and see if that helps. Still, there's another 10k brushes outside of your terrain, which seems like a lot (unless you've got some curved geometry).

Re: MAX_MAP_DRAW_INDEXES

Posted: Fri Jul 20, 2012 3:08 am
by vulture
P.S. I went back and checked on my old uber map, it was actually # planes I had that was massive:

Code: Select all

brush total: 32073
plane total: 181966
pmesh total: 130

entity totals:
  brush: 189
  point: 683
  light: 2126

05/14/2012  10:27 PM        41,372,436 gen.bsp

But I'm still able to load with com_hunkmegs 128, so it's got to just be something about strange your map.

Re: MAX_MAP_DRAW_INDEXES

Posted: Fri Jul 20, 2012 7:42 pm
by RedSnappa
Maybe I should just link my .map file here to see if someone can tell me what I have done wrong. I am also having MAX_MAP_VISIBILITY issues when I try the VIS stage of compiling. I probably just need a lot more hint brushes though.

Where is a download link for Rambetter's q3map2?

Re: MAX_MAP_DRAW_INDEXES

Posted: Fri Jul 20, 2012 7:45 pm
by Rylius
Hint brushes won't help you at all, the map is way too open for VIS to have any effect. You could leave it away and it won't change much.

Re: MAX_MAP_DRAW_INDEXES

Posted: Fri Jul 20, 2012 7:48 pm
by RedSnappa
Deleted post

Re: MAX_MAP_DRAW_INDEXES

Posted: Mon Jul 23, 2012 12:25 am
by vulture
I'm not sure what a good way would be to select and delete all of your terrain brushes would be, but that'd be a good place to start, just to see how much space that costs you (as per my suggestion in my long post above).

Re: MAX_MAP_DRAW_INDEXES

Posted: Mon Jul 23, 2012 1:04 am
by RedSnappa
Great news everyone. The error had nothing to do with my map, and everything to do with the fact that I forgot to cut down some .wav files. I had one that was 4 minutes long and 42 MB in size. Now that this is cut down to ~9 seconds and 700 KB, the map loads without any problems.

I doubt that I can get VIS to work on something like this, but at least it will run now. I suppose the next thing I will try is to make all of my terrain brushes details and put some structural brushes just beneath the surface of them in a much smoother fashion.