Lighting Your Maps, part 2Co-authored by Tony "Mad Dog" Ferrara The first "tutorial" on Light covered sunlight, shadow, and area lights. This discussion will focus on texture-based lighting, colored lighting, special effects lighting, and related problems. Let's start off by looking at colored light. Colored LightThe first rule in using colored light is: Does it make sense? In other words, if I'm playing your level, and I rush into a room that has pulsating red light, there should be a reason for the light. I'll be expecting a reactor meltdown, or a console emitting a warning light, or something that connects the red light to its source. Just placing a pulsing red light into a room without origin or reason is pointless. If you've got a ho-hum map, don't add such lighting in order to "improve" things. Stained glass windows are a good example of when colored lighting should be used. Notice the cheesy attempt in the screenshot below: In order to try and re-create "volumeric" lighting, I made a brush, applied the stained glass texture to it, stretched the texture, and used the Surface Inspector to make the "beams" of colored light mist, trans33. However, it's unconvincing and asks the rendering engine to re-create something it wasn't geared to do. In the game, the brush making up the shaft of colored light has hard edges and actually looks like a glass tent that the player can walk through. Now look at the next screenshot: Here, I checked the light flag on the stained glass, with a value of 1000, hoping for a quick answer. Then I threw six different-colored lights around, hoping to get the effect. Instead of bathing the area in multi-colored light however, I ended up with white light. Why? The sum of all color equals white. No colored light, just white. As you can see from the shot above, this is the most natural-looking setting. I lowered the light value on the stained glass to 100, and placed 10 light entities near the floor, with light values of 150 and _focus values of .1. As you can see from the editor screenshot below, each of the lights are a different color. I probably could have done it with less lights, but you get the point. Texture-Based LightingVirtually any texture can be made to produce light. Simply select the texture, check the light flag, and input a value. ArghRad takes the average value of all the colors in that texture to calculate the light color. Here is a shot where I turned the ceiling texture into a light. See how the room has a barfbag pinkish cast? This is because the white panel is mixed with the pink and brownish pixels that make up the entire .wal file. Light coming from ceiling texture with the light flag set Here's the same room, this time, with the ceiling texture NOT emitting light. The light was provided by adding three white area lights near the ceiling, each with a value of 75, a _focus of .1, and a _fade of .1: Light coming from area lights placed near the ceiling. The area lighting makes the room look more natural, but still makes the player believe that the light is, in fact, coming from the ceiling. More could be done to improve the lighting, but the point is, try different methods and go for the best results. Oh, yeah, the dead guy on the floor? He was trying to mess with me while I was taking pictures. I had to snuff 'im. Suspended Ceilings To make a suspended, or "dropped" ceiling, first create a texture in Wally to look like a ceiling square---white, with a 1-pixel light gray border. Set the light flag and you've got a believable dropped ceiling for an office scene. To enhance the realism, duplicate the texture, except animate it with several frames of differing light values to make it appear like one of the florescent bulbs is flickering. Place this texture on a couple of brushes apart from the main ceiling brush. NOTE: In some openGL cards, "pure" or solid colors with RGB values in the upper range do not come across well. If that's the case, use Wally to add some noise (Effects menu). If used only for texture-based lighting, they should be OK, without noise. Here's an example of texture-based lighting, showing simple "track" lighting, with the bottom brush face sporting a white texture with the lightflag set to 1000: Screenshot from my DooM re-creation, "Thy Flesh Consumed," E4M3 Shoot-able LightsEver play a level that had some cool light prefabs in it, yet they always withstood the onslaught of heavy firepower and never went out? If you have a room where there's going to be a lot of firefighting going on, it adds to the realism when the room gets darker and darker as the lights get shot out one by one. It's not that hard to do. Setting up a light that will go out when shot. As you can see from the screenshot above, the func_explosive is targeting both the speaker (breaking glass sound) and the trigger_multiple, which, in turn, is targeting the light entity. The func_explosive is the glass sides of the light prefab, which I've moved in order to show you more clearly the set-up. Download the map here. Hallway "Ripple" LightingEver see a movie where lights winked out down a very long hallway, the hall shrinking down into a black tunnel? The same effect can be achieved using trigger_relays. We're going to make a long hallway where four lights go out in sequential order and three lights come on. Here's how: 1. Create a long hallway (I made mine from 0 to 2176, too long for decent r_speeds, but perfect for this tutorial) 2. Add a light entity at one end and a trigger_relay. The light should have a _focus of .1 and a _fade of 1. 3. Target the trigger_relay to the light. Bring up the entity dialog and add a delay value of 1 to the relay 4. Copy the trigger_relay and the light and make six clones, stringing them at equal distances down the hallway. 5. Go back and change the delay values for each trigger_relay to 2 thru 7. Remember the first trigger_relay had a value of 1; don't change it. 6. At the left end of the hall, add a trigger_once. Select this, and while continuing to hold down the left shift key, select all the trigger_relays. 7. Press CTRL-K and then ESCape. The trigger_once should now be targeting all of the trigger_relays. 8. Finally, select the last three lights at the right end of the hall, press N, and flag the Start_Off spawnflag. Add a player start and compile the map. Run down the hallway. You should see the lights go out as you pass under each one. The last three should wink on as you run under them. Or, if you're out of shape, you can simply stand there and watch the lights do their thing. If you want to see how it's done, grab the map and .bsp file here. Face with Too Many Lightstyles ErrorAvoid small _fade values when using switch-able lights. They cause the light to travel too far which leads to lighting errors. You have to construct things so that no single coordinate on any brush face ever gets hit by too many lightstyles. In the hallway example above, note how far apart the light entities are placed. Although we had room to spare, bringing them too close together would have given us the too many lightstyles error. The _fade value of 1 prevented the light from "reaching" too far. If we would have set the _fade value to .1, the light at the far end of the hall would have reached almost to the opposite end of the hall. Do that to all seven light entities, and you've got every light lighting every texture. Not good! What makes a point light a distinct lightstyle? The "style" key, obviously. However, two or more lights with the same style count as one lightstyle. The other reason for distinct or different lightstyles is caused by using targetnames on your light entities. Here's a simple map with nine lights in a single room, each sharing the same targetname: When we compile the map, here's what it looks like in the game: Here's the exact same room, but notice the difference: What happened? In the screwed up map, every
point light has a different targetname (light1, light2,
...etc), even though there are no triggers in the map. Because they
have targetnames, they are saved in the .bsp as switch-able
entities. Therefore, the map looks like it does because it's missing
lightmap data, due to the lightstyles error. Some lights are not lighting
some faces, although they're supposed to. Point lights without targetnames are used to generate lightmaps during the rad process. Once the .bsp file is radded, they are then discarded. Point lights with targetnames are retained as ents, in the event they are ever targeted by something. Therefore, giving point lights a bunch of different targetnames for no reason is asking for trouble. No harm is done giving them all the same targetname. One caveat however: when they are retained as ents, you can run into the game error, no free edicts. Since the no free edicts error is somewhat complicated, see David Hyde's explanation here. Custom Light EntitiesMappacks can give you lighting effects beyond what standard Q2 entities offer. Lightning, rotating beacons, and shoot-able deathmatch lights are all available in Omega Development's mappack. If you're looking to breath new life into your maps, check these guys out. Copyright 1999, by Terry DeLaney. Permission is granted to distribute this file as long as the author receives credit. |