QRAD DOCUMENTATION qrad [parameters] bspfile PARAMETERS YOU MIGHT WANT TO USE -bounce <0-???> default: 8 Specifies the number of light bounces to perform. 0 gives direct lighting only, and does not calculate any transfer functions, giving a very fast run. Under a minute for a level with vis info, a few minutes without. Because most of the time in full runs is in the transfer function generation, the number of bounces greater than 0 is not a crucial speed factor. -chop <16 - 256> default: 65 Determines how finely patches will be chopped up for the radiosity process. Smaller number give better results, but use quadratically more ram and time. You can use larger values like 96 or 128 to get the light properly dispersed in the level (no need for a -ambient) but still take lots less time than a full process. The older qrad used a chop of 49, but it didn't do the direct lighting as a seperate step. -ambient <0.0 - 1.0> default: 0.0 This value is added to every light sample before any lighting is done. An ambient of 0.1 (10%) or so can be used in conjunction with a -bounce 0 to get a very fast aproximation to the full process. -maxlight <1.0 - 2.0> default: 1.5 If set to 1.0, no surface will ever be overbrighted, no matter how much light shines on it. Artist types may push for this to keep their textures from being abused by the overbright tables. PARAMETERS YOU AREN'T LIKELY TO USE -verbose Turns on more detailed statistic printing. -dumppatches Development aid -- writes bounce0.txt and bounce7.txt polygon files for visualizing the radiosity process with glview.exe. -threads <1-???> default: number of cpus Specifies the number of threads to use for calculations. Set to 1 to isolate potential multithreaded errors. -scale <0.0 - ???> default: 1.0 Multiplies all light values by this factor to brighten or dim the entire level. If you are just way off either overbright or almost black, you can easily try scales like this. USAGE IN DEVELOPMENT You should do a vis before performing a qrad. All of the lighting tests are accelerated by the PVS information. If you haven't vised the map, subdiv will be forced to 9999 to keep it from taking all day to complete. Even a fast vis will help. The first part of the radiosity process is the accurate calculation of direct lighting. All entity lights and the bright (5000 or greater) surface patches exactly trace lines to the individual lightmap samples. If -bounce 0 is specified, thats it for the lighting. Otherwise, the lightmap values are summed up to give the initial amount of light to be bounced around the world in the radiosity pass. SURFACE LIGHTING All textures that are on the "light emiting" list will cast light into the world, oriented down the surface normal. The lights.rad file is found inside the game directory (f:\quake\id2, etc). It contains a list of texture names and the amount of light they emit. A value of 100-300 is reasonable for a large, dim surface, like slime, lava, or a dark sky. Lights that will illuminate large areas with a small surface area will have values of 5000 or greater. The total amount of light emited from a surface is proportional to the surface's area, so the size of the brush face has as much effect on the light sent into the world as the light value. Surface lighting falls off with the sqare of distance, so if you double the height of a room, you will need to have four times the light intensity on the ceiling to get the floor the same brightness. The walls would then be much brighter near the top than they were with the smaller room as well. SKY LIGHTING Skys emit light like other surfaces, but have slightly different characteristics. They emit light from all angles, so it doesn't matter if you see a horizontal or vertical sky brush. Light also does not bounce off of a sky in the radiosity pass, if it flies out a sky texture it is just gone. ENTITY LIGHTING You can use "light" entities to have light come from space without a surface. A level designer goto. They should function similar to quake 1 lights, with linear falloff instead of inverse quadratic. The new class "light_spot" can be used to make a spotlight. If it is targeted at another entity, the spotlight will point directly at it, otherwise it will point in the direction of its "angle" field, so you can easily make simple axial pointing spotlights. The field "_cone" determines the spread of the spotlight. If not specified, a _cone of 15 will default. ISSUES WITH BMODELS Brush models emit and absorb light like other surfaces, but they do not block light, so after normalization, a little less light lands on the nearby surfaces, because it was absorbed both by the door and the surfaces beyond it. You probably won't notice anything unless you have a row of spotlights on normal walls, then an identical one on a bmodel. ISSUES WITH WATER Light does NOT cross through water surfaces if the vis has been calculated, because the areas are in different potentially visible sets, but if you run qrad without a vis, then light will be sent through as well.