Reducing BSP file size.

Discussion for Level editing, modeling, programming, or any of the other technical aspects of Quake
Post Reply
Pat Howard
Posts: 494
Joined: Tue Mar 31, 2009 11:14 am

Reducing BSP file size.

Post by Pat Howard »

After a short break, I'm now polishing up the alpha for what was going to be my NoGhost Competition map.

The thing is absolutely monstrous. It's over 3k brushes in just an alpha (!), though it's mainly from copy-pasting arches/stairs. It's going to be a highly detailed map too. The final brush count is going to be really high. 20k, 30k? IDK.

I remember this map couldn't do a full vis compile because it was over some weird 30mb limit. This is an engine limitation, right, so that means there is no work around?

If so, I want to start planning for this now. Any suggestions for keeping the file size low? Do some of the factors listed below have a far greater effect than others?
  • Lower res. textures?
  • Lower brush count?
  • Minimize amount of light sources?
  • Did this guy just make some noob mistake, like not making everything detail?
  • Are there any other limitations with map size in Q3A that I should know about?
Any suggestions appreciated.
-pat
dONKEY
Posts: 566
Joined: Mon Oct 15, 2001 7:00 am

Re: Reducing BSP file size.

Post by dONKEY »

I might be wrong, but I thought you could change the default blocksize to get around vis limitations. I think that was done on the larger terrain levels.
Brush count and tris count are NOT the same thing. Quite often I will clip more brushes in order to create fewer tris in game (to control face splits). Lightmap resolution can inflate bsp size hugely.
jal_
Posts: 223
Joined: Mon Mar 24, 2008 4:13 pm

Re: Reducing BSP file size.

Post by jal_ »

The most important factor for bsp file size is lightmap data, and I don't think you want to make it smaller than the default (although at terrains or smooth surfaces it can be without much quality harm).

Besides that, making brushes detail will reduce it (will reduce vis subdivisions) and making it models will reduce it more (will reduce vis subdivisions and triangle splits). I don't think there many more things that can be done.

EDIT: The amount of light sources has no impact on the final bsp data size, they are just used to light the lightmap. Textures are not included in the bsp file either.

Many of q3map2 size limitations are arbitrary. If you use netradiant's q3map2 they won't be there.
obsidian
Posts: 10970
Joined: Mon Feb 04, 2002 8:00 am

Re: Reducing BSP file size.

Post by obsidian »

Caulk all unseen faces so lightmaps won't be generated for them.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
AEon
Posts: 1816
Joined: Sun Apr 20, 2003 7:00 am

Re: Reducing BSP file size.

Post by AEon »

obsidian wrote:Caulk all unseen faces so lightmaps won't be generated for them.
On detail brushes!... the good old structural brushes remove unseen faces automatically.

IIRC, things like -samplesize 4 in the q3map2 compile (was it -meta stage?) were evil.
obsidian
Posts: 10970
Joined: Mon Feb 04, 2002 8:00 am

Re: Reducing BSP file size.

Post by obsidian »

-samplesize isn't evil, you just have to be careful how you use it since it is global and will scale all lightmaps universally unless specified otherwise by entity keys or in the shader file.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
Pat Howard
Posts: 494
Joined: Tue Mar 31, 2009 11:14 am

Re: Reducing BSP file size.

Post by Pat Howard »

Cool, thanks guys.
sock
Posts: 424
Joined: Sat Sep 09, 2000 7:00 am

Re: Reducing BSP file size.

Post by sock »

Large maps are possible but you have to plan a lot for how they will grow. I am not sure about the 30Mb BSP limit, but I have hit a lot of other limits. My latest project 'Map on the edge of forever' is about 23K brushes and still growing, got 2 more areas to complete yet. Here is a quick image from the editor to show the scale of the thing.

[lvlshot]http://www.simonoc.com/images/design/maps_q3/moteof1ef_editor1.jpg[/lvlshot]
Key: Blue is grouped brushwork, Orange is ASE models.

The number one killer of file size is lightmaps and how you scale them. Personally I would recommend you only add the lightmapscale key to things that really need it (angled architecture, stuff close to the player, special vista areas) and then always try and start with high values (0.5) and go towards (0.125) low values when you really need it.

Make sure your architecture is as modular as possible and use ASE models where ever possible, because they are perfect for good texture alignment and individual lightmap tweaking. Never get too attached to any one area because when you deal with huge maps you may have to cut sections because of engine limitations.

Do not use any ambient lighting because it just creates flat and pointless lighting! (bad lighting joke :p ) Sort out your sky sunlight angles very early on because changing it later will cause you a lot of pain, especially if you have setup all the lightmapscale keys for maximum visual impact on light angles.

Hint and portal your map very early on because once the detail is added it will be awkward to fix later. Always do a full compile of your map at least once a week to check that the whole map can load into the engine without any errors. I know it is handy to work on region/sections of a map especially when tweaking lightmaps, but it is always wise to know if everything still works.

Everytime you work on the map create a new revision and if you are experimenting with different architectural detail styles save them off into seperate map revision. This has saved me so many times that I have lost count. I often find that I can go back to later revisions and grab stuff that did not work at the time and re-use it elsewhere. Multiple revisions are also handy for comparing how lightmaps look and are a good indication of how fast the map is growing in size.

Start with high resolution textures (512x512) for your basic block sizes and scale stuff up or down depending on how close the player is to the surface. Textures are loaded seperately to the BSP file so it does not affect that limit. Set up your Q3 engine to the default com_hunkmegs so that you got an idea of what limits you are hitting and when. Try to squash all your texture trims on to single large image, because it will make the map more efficient at loading and help with video card memory texture swapping.

Hope that helps and good luck with your new project.
Well he was evil, but he did build alot of roads. - Gogglor
My [url=http://www.simonoc.com/]Website[/url] & [url=http://twitter.com/SimsOCallaghan]Twitter[/url]
Pat Howard
Posts: 494
Joined: Tue Mar 31, 2009 11:14 am

Re: Reducing BSP file size.

Post by Pat Howard »

Thankyou, Sock, that's some very useful info. I'm still not sure exactly what happens behind the scenes when Q3A runs out of memory - maybe someone could explain it to me?

Could you also explain the "individual lightmap tweaking" on ASE models? I don't think I've ever messed with lightmaps before other than one lightmapscale test to see how it worked. Now that I think about it, Q had some nasty shadows that would've benefited from lightmapscale tweaks.

I'd be interested in hearing some of the other limits you've hit. MotEoF is really a beast. Can't wait to play through it!
^misantropia^
Posts: 4022
Joined: Sat Mar 12, 2005 6:24 pm

Re: Reducing BSP file size.

Post by ^misantropia^ »

Pat Howard wrote:I'm still not sure exactly what happens behind the scenes when Q3A runs out of memory - maybe someone could explain it to me?
Nothing really, it simply drops back to the menu. If you are hitting the memory limit and there is nothing you can shave off your map, the only solution is to bump com_hunkmegs.

EDIT: Though there are some hard-coded limits, like no more that 16K shaders, 256 lightmaps, 64K surfaces per frame, etc. but they are all pretty large.
User avatar
monaster
Posts: 532
Joined: Mon Apr 28, 2008 1:52 pm

Re: Reducing BSP file size.

Post by monaster »

sock wrote:I am not sure about the 30Mb BSP limit.
Yep, it's true. Q3 can only handle bsps up to 30 MB.
If you are caught on a golf course during a storm and are afraid of lightning, hold up a 1-iron. Not even God can hit a 1-iron.
-Lee Trevino, golfer who actually has been struck by lightning.
Post Reply