OpenArena
Register
Advertisement

Realtime or pre computed global illumination in id tech 3 engine doesn't exist. One could think about painting lighting by hand directly on exported lightmaps, but unless one's brain can visualize lighting in 3D and abstract the projection on 2D, unwrapped, surfaces, that's insane work to do.

Once sad that map illumination is computed during "light stage" of Q3MAP2 compiling process, let's see how to bring some more light to dark spots of your maps without actually adding extra light sources.

There are some ways to fake indirect lighting in current q3map2 version: ambient light (don't use it, it's terrible!), _minlight (not very good), floodlight and radiosity.
For some infos about "ambient" and "_minlight", check Mapping_manual/Lighting#Ambient_light. For infos about "floodlight" and "radiosity", continue reading.

Floodlight[]

Shot0000
Shot0001
Shot0002
Shot0003


Ambient light is terrible, it disregards depth and shadows and lights up every pixel with the same brightness value. Floodlight fixes that by faking ambient occlusion, light becomes darker in closed spaces and brigther in wide open spaces.

In worldspawn add a new key called _floodlight. The values are, in the order that they are typed:

-RGB color values, in the non-normalized 0 - 255 scale, or in the normalized 0 - 1 scale.

-Distance to trace. Higher values make the light rays travel distance longer, resulting in darker lighting. Lower values produce the opposite effect, light rays travel distance is shorter, resulting in overall brighter lighting. Try to guess the best value based on the overall wideness of your map.

-Intensity. The floodlight's intensity. Float value.

Note that floodlight "floods" the whole map, there is no control over per area flooding.

Radiosity[]

Shot0004
Shot0005
Shot0006
Shot0007
Shot0008
Shot0009

q3map2 fakes radiosity by generating lights right in front of surfaces hit by direct lighting (-bounce x parameter sets light bounces).

In light stage, add -bouncescale x switch. It'll multiply the intensity of lights generated by light q3map2's radiosity by x, where x is float. This will "overpower" light bounces, creating strong indirect lighting and strong color bleeding. The side effect is that this will also create overbright spots here and there on corners. There is no workaround those overbright spots because that's how q3map2 generates radiosity in the first place.

If map becomes overbright everywhere you can compensate with -compensate n.n in light stage and/or q3map_lightmapbrightness n.n on all surfaces, meaning that you'll have to have shader scripts for every lightmapped texture in your map. In turn, -compensate n.n has another side effect, it darkens places that are already dark. To compensate for this last side effect use -gamma x in light stage to multiply the lightmap's gamma by x, where x is float.

External render[]

It's currently an unfeasible idea. You'd have to manage many UV channels / coordinates / seams and many models at once, all by hand (unless there is an automated way of doing this). Then, after baking the lightmaps in some external render (Vray, Mental ray, etc), you'd have to import the model(s) back in the map editor to do vis and structural brushes. Finally, compile the map.

Sounds fun?

If the engine doesn't support multiple UV channels per model, then the above workflow is undoable.

See also[]

Advertisement