Quake3World

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

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.

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.

Caulk all unseen faces so lightmaps won't be generated for them.

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.

-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.

Cool, thanks guys.

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 ) 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.

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!

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.

sock wrote:I am not sure about the 30Mb BSP limit.

Yep, it's true. Q3 can only handle bsps up to 30 MB.