Quake3World

...and why?

I'm looking for a high quality compile without "too much" compile time (some switches speed up the process considerably, especially in the light stage).

I have searched the forum here but haven't found anything conclusive.

I have used these settings for my last map (a long time ago):
BSP -meta,
VIS -fullvis,
Light -bounce 8 -fast -filter -patchshadows -samples 2 -super 2,
BSPC -forcesidesvisible -optimize

Without taking into account the aas compile, wikipedia comes up with these settings:
BSP -skyfix -rename -meta -samplesize 4 -v
VIS -v
LIGHT -bounce 3 -fast -filter -gamma 2 -patchshadows -samples 3 -v
wikipedia A final good compile

Below are the "extra" switched I haven't used before:

BSP:
-skyfix: "Enables fix for buggy ATI GL_CLAMP behavior. Always use this."
-rename: "not sure exactly what it does but I will just call it magic as it makes the ugly black models in sof2 show up with the right colors (if you are using misc_model in your map use this switch)"
-samplesize: "Writes the prescribed samplesize argument to the .srf surface file. The .srf file (and thus -samplesize) affects the -light phase of compile. A lower -samplesize value produces more sharply defined lightmaps. The default samplesize is 16; a samplesize value of 4 produces a very high quality compile, suitable to call "final." A samplesize value of 1 would be total overkill, resulting in epochal compile times and immensely bloated .bsp filesize."
-v: "Enables verbose mode for the bsp phase. Always use this." (for all stages).

VIS:
-v: see above

Most noticably are the switches in the light compile:
LIGHT:
-bounce 8: I read somewhere this is a high quality setting, yet Wiki recommends using -bounce 3, this will save a lot in compiling time, comments?
I used -filter, however Wiki says(! even though their "final good compile" uses the same switch...?): "Applies a gaussian blur to lightmaps, smoothing out shadows. Sounds good in theory, but -filter doesn't play nice with a lot of the more interesting effects... don't use it. Use -samples instead."
gamma: "Creates a more realistic color ramp between "light" and "dark." Good values are in the 1.4-2.2 range. Games that use r_overBrightBits and r_mapOverBrightBits (Quake III: Arena, most notably) will need those cvars disabled unless -compensate is used accordingly."
-super: "Enables arbitrarily ordered grid supersampling of lightmaps. This is much, much, much slower than -samples, by the way." Wiki does not recommend this setting in a final compile...

I am not sure whether to use thes switches:
-bounce 3/8
-bouncegrid (not used in Wiki's version, read afterwards it's used)
-dark: "Enables darkening of lightmaps at brush/lightmap seams. Sort of like a half-assed occlusion pass, ends up looking a bit Unreal 1-ish. Very subtle."
-dirty: "Enables ambient occlusion or "dirtmapping". Basically, less-visible areas (such as nooks and crannies, cracks and crevices) will become darker. This simulates a dirty, grimy effect. Check the 2.5.14 release thread for further details."
-fastbounce: "Enables -fast style calculations, but only for radiosity lights."
-fastgrid: "Enables -fast style calculations, but only for the lightgrid."
-filter (contradiction)
-super 2 (same, not used, yet I read it was good)

Yes, I can see how the wiki's descriptions of -filter and -samples might be confusing. But when I wrote that example of a "good final compile", I just did it based on aesthetics. Going strictly by technical definition, -samples should do it "right". And -samples (alone) does in fact look better than -filter (alone) does. However, in my experience, throwing -filter at it on top of -samples makes things look even better.

The radiosity calculation is limited to 3 because I found 3 bounces to be pretty optimal as far as bang-for-your-compile-time-buck is concerned. Sure, 8 bounces will look a tiny bit better, but is it really worth the extra hours you waste waiting for the compile? Not in my experience. Just stick to -bounce 3 and you'll be fine. If it's really bugging you, you could go up to -bounce 4, but honestly you won't be able to tell much of a difference.

In my opinion, the -gamma switch is awesome. It fixes a limitation in the available color gamut in Quake III. When compiling for Quake III, I think you should always use -gamma 2 -compensate 4. That said, some people don't like the way -gamma looks (it does look fairly different from "traditional" Quake III lighting--slightly less contrast, greater range of color). You should try your map with and without the -gamma (and -compensate) switches to see what you like best.

Don't use -super, the -super switch is way slow compared to -samples and it basically does the same thing but on a needlessly larger scale (-samples only does the supersampling on shadow boundaries, while -super does supersampling everywhere... i.e. even on the flat-colored areas of a fully black shadow).

The -dark and -dirty switches will alter the aesthetics of your map pretty drastically, if it works for you and is a visual effect that you like the looks of, good for you, go for it.

Don't bother with -fastbounce, -fast is all you need (-fast turns on "fast" mode for everything in the lighting phase, you don't have to turn on the individual "fast" modes for the separate lighting calculations of the lightgrid or radiosity in addition to the general -fast switch).

So yeah, the command line in the wiki is awesome. It's basically what I came up with after talking shop with ydnar for a year or so.

ALL OF THEM!

The reason I havent released anything in the last 3 months is because im still compiling..

Thanks a lot rgoer

I will test some of the more exotic switches to see what they do (-dark, -dirty).

StormShadow wrote:ALL OF THEM!

The reason I havent released anything in the last 3 months is because im still compiling..

Hmm... I've been compiling without -v on my light stage (like alwasy). Is that bad?

Doesn't change anything, just adds verbose.