Hey everyone, if you think of something that would be good for the site, please send me the idea to Doug@tophattwaffle.com

If you’re even reading this right now it’s because you use Hammer editor, and know that is can be a black vortex of your time. Knowing how to work through a project without giving Hammer too much of your time is always a wonderful thing to do. You could be spending that time on having a life in the great outdoors, or making another level in hammer. So with that you are the artist, and that newly created map file is your canvas. Lets turn it into something wonderful.

Planning Stage

Planning your level can do wonders for the time spend creating the level. It also helps reduce the amount of reworks that do you because you think that you can do better. When planning your level out you should know your skill cap, and the limitations of hammer along with the engine. Planning to do something that you can’t, or something that is impossible for the engine is a waste of time and will make you feel like crap for wasting your time on it. So keep it simple, working around you. If you see something in another level and want to emulate it for your own level but don’t know how find out. You can either contact the creator of that level and ask for help on the situation, or decompile the level. Now when I say decompile the level, I’m saying this as a learning purpose only. If you go and just copy what they have made you’re not learning anything, you’re just hurting yourself.

Once you have the idea in your head you might want to get it onto paper, or some other form or medium that you can store it in. You don’t need to be Van Gogh with your design when putting it onto paper. You are most likely the only one that is going to be looking at in anyways. Here are some of the doodles that my Lab Rat team have come up with for designs.

As you can see they are by no mean pretty, but they get the point across. You mainly want it to prevent you from forgetting what you wanted to do. You might find that you will constantly get ideas for your level just going about your daily life. I get a lot of mine right before bed and I keep a notebook near by so I can jot them down before I go to bed. If you’re not the kind of person to doodle, then you can always just make a rough outline in hammer with the dev textures. It takes no more than 20 minutes to lay out an entire level.

Start Mapping

You now have your layout, and you’re most likely feeling like you’ve gotten a lot done. This is in fact not that case! I don’t want to burst your bubble but the longest part has just begun. You now start building your level in hammer, for all of the screenshots in this I’ll be using one level that I’ve made. (a level for Portal 2 Lab Rat.)

You might not even know where to begin your level, believe me we have all been there. I’m also sure we all start at the same spot, the player spawn. It’s best to make your level the same way you play it, start to finish.

You can now build your level in two different ways:

• You can build in passes. When building in passes you doing things 1 pass at a time.

1. You do the brush pass. You lay out the entire level in brush. Place no models, and do no detail work at all.
2. Functionality pass. You then go back and all of the functionality parts of the level. This is stuff like doors, entity systems, anything that the player HAS to do to complete the level.
3. Detail pass. You go back, and add full detail to your level. In this you would place all of your models, lights, sounds, and everything else that your level is missing.
4. Test pass. You test the entire level, then go back and fix what you found to be broken.

• You can build in areas/steps. When building like this you build like the pass method, but you do it one room at a time. You fully complete one room, before moving onto another room. You are basically breaking down the map into little maps, and finishing them faster.

Work Flow, and Time Management

Your time is precious, and you need to spend it wisely. This can be done by having good work flow, basically a lot of little things to help speed up the total process. One of the biggest things that you can do to speed up mapping is to use the mouse as little as you can. No matter how fast you may think you are with it the keyboard is always faster. So use hot keys, the time you spend by pressing the hot key is less then moving the mouse from where ever it to to Edit->Map properties. Here is a complete list of Hammer’s hot keys to help you speed up the process. Hammer Editor Hot Keys. Once you’ve started using hot keys you should find that the whole process is a little faster, does it not feel good to be a keyboard warrior?

The grid is a wonderful thing to help stay organized, and hammer enjoys when things are on it as well. Without getting to much into optimization the grid helps you stay sane, because there won’t be a ton of lines scattered all over the place.

Sense vision is so important to us we need to help keep it clear. While starting the level off you can see everything fine because there is not much there yet. But give it time, soon your level will be filled by your masterfully placed brushes, and props. Yet when the grid gets too cluttered you’ll need to clean it up, and you’ll use vis groups for this. They allow you hid certain things from your level so you have better vision of what you’re working on. You can also toggle prop, and displacement from bring drawn to just the bounding box. To toggle this just click the “Toggle Models in 2D” button, it’s located 2 icons to the right of “Run map” and looks like this:

Here is what it looks like when you have them enabled, and disabled.

You can see that on the left there is so much more going on, and it’s hard for me to see what I’m doing. Where as on the right I can see exactly what I’m doing. You can see my vis group’s filter control to the left. In it I have my map organized into the areas of my map, I can easily toggle what I do and don’t want to see. If you want to know how to create vis groups you can watch: Tutorial 39, Vis grouping.

We all like to test what we’ve just made, and sometimes we are doing a lot of testing because of the guess work we are doing. But with every test you are required to compile your level. Depending on how good your computer is, and how well the level is optimized the compile can take anywhere from 5 minutes, to 3 hours. Knowing what compile settings are needed to test your level are very important. If you’re just testing entities you don’t need VVIS or VRAD, so you can just compile with VBSP. The level will be laggy, but you will only spend 15 seconds compiling, compared to the longer compile time including lighting and vis data.

But testing lighting information can be a little longer, because VRAD needs to fire rays so it knows how to light your level. You can test certain level of you area by using the cordon tool.  When you use the cordon tool it hides everything outside of the cordon box, and seals the map from leaks. This will allows you to test lighting much faster, because you’re only compile a room, as opposed to compiling the entire level to just test said room.

 Finalizing

You are now moving on to last bend of the mapping process, finalizing. At the end of this  is a check list on how to finish up a level, but I’ll write out some of my thoughts on the process, but the check list is king!

There are a few things that you need to do, make sure you have cubemaps added to your level. The cubemaps are what the engine use for cheap reflections. Add them, then buildcubemaps. Then you need to make sure the FPS is acceptable in your level, this means optimizing your level, not one likes it but it has to be done. If you don’t know how to do this watch: Tutorial 21, Optimization. Then compile your level on normal settings, you don’t want to do a final compile here because you’re just doing a test run here. (If you want to test with the advanced compile settings you can.)

Next run though your level, find any and all bugs that you can and fix them. Next you’ll want to send your level off to some testers, don’t send it to everyone on your friends list. Once you’ve sent it to your tester(s) make sure they know it’s a beta, and that they are to find any problems they can. Listen to them, I’ve made this mistake before thinking that I knew what was best. Not everyone thinks like you, you may have made things hard to find and will need to place some hints to nudge the player along in the right direction.

After you’ve fixed all of the problems that your testers have found fix them, then run though one more time and see if you have made any more problems by fixing the previous bugs. If you’re all good then pack the level (if needed, you’ll only need to do this if you have custom content in the level.) After the packing you are all done!

I hope that this is what you guys meant, and wanted by a “work flow” tutorial, if you feel I’ve missed anything let me know and I’ll try to fix it when I can. Thanks, and happy mapping!!! <3

Finalizing a level check list

1. Add env_cubemaps to your level.
2. Optimize your level. (If you don’t know how, watch THIS)
3. Do a rough compile of the level. Compile with VRAD and VVIS set to normal.
   1. If compile takes long on VVIS, Go to your level and make sure you have func_detailed the correct things. (If you don’t know what “func_detail” is, watch THIS)
4. Build cube maps, type: “Buildcubemaps” in console for this.
5. Play through your level for about an hour or more. Look for game play and visual flaws, then correct them. If none Start back at #3.
6. Get (a) friend(s) to play your level, have him/her look for game play and visual flaws, then correct them. If none Start back at #3.
7. If your map has passed the testing phases you can move on to the Final Compile
   1. Settings up a final compile takes a few steps, first click “run map”
   2. Click “Expert”
   3. Click “Edit”
   4. Select Default, and Click “Copy”
   5. Name it: Final Compile (Slow)
   6. Select “Final Compile (Slow)” from the drop down.
   7. Under “$light_exe” add the following to the parameters, before “-game”: -final -textureshadows -hdr -StaticPropLighting -StaticPropPolys
   8. Add a new command, put: $light_exe in the command area.
   9. Add the following to the newly created commands parameters: -final -textureshadows -ldr -StaticPropLighting -StaticPropPolys -game $gamedir $path$file
   10. Move the new command to be above the old $light_exe command.
8. Compile the map under the new compile settings.
9. Build cube maps again, type: “Buildcubemaps” in console for this.
10. Toggle HDR modes. (If it’s on, turn it off. if It’s off turn it on)
11. Build cube maps again under the new HDR settings, type: “Buildcubemaps” in console for this.
12. Close the game.
13. Pack all your custom content (if any) into your level using: PakRat, VIDE, MAN, or PackBSP. (PackBSP does the best job)
14. Remove your: Materials, Models, and Sounds folder from your root directory of your game. (Rename them, move them to desktop. Just make the game create new ones)
15. Load the packed level, make sure the map packer got all of the custom content into the level. If not, go to step 13 and try a different packer.
16. If everything is good to go. Release the map.

Someone over at Type3 asked me if I could make a quick tutorial on clouds for the 3D Skybox. So here it is!

First off let me say that this is useful for ALL source engine games, but if you’re mapping for Counter-Strike Source you can always use the models for this. Yet if you want a custom look you can always use this!

1. You’ll first need a texture to use for your clouds. I’ve made the one in the screenshot above using FilterForge, but you use what ever your little heart desires.

I’m going to skip showing you how to make one because either you have photoshop/GIMP and know that it can render clouds, or you don’t have those and will ask for a download anyways. So you can download a pre-made pack of clouds made by me here: [download id="136" format="2"]

2. (If you downloaded my pack skip this) You will have to make a VMT for them. The VMT will have to have it not receive light, scroll the texture, and make it transparent. So using the VMT code below you can get all of that nice and easy.

"UnlitGeneric"
{
	"$basetexture"	"CloudsClouds1024"
	"$translucent" "1"
	"Proxies"
	{
		"TextureScroll"
		{
			"texturescrollvar"	"$basetexturetransform"
			"texturescrollrate"	".008"// Change this to change the speed of the clouds
			"texturescrollangle"	"65"
		}
	}
}

3. Now you have to implement this into your level. So create a 3D skybox then create a brush covering the whole skybox.

4. Make the BOTTOM FACE ONLY a displacement and check:

• No Physics Collision
• No Hull Collision
• No Ray Collision

5. Next go to paint geometry, and set radius to the smaller of your two sides. Mine is 5912. Then place the painter in the middle of the displacement and raise it up so it is a dome shape.

We make it a dome so that the edges go behind the items we have in our 3D skybox so it looks flawless.

6. If you want your sky to look like it’s a cloudy day just copy the cloud displacement up, and change it’s scale and XY shifting. By changing the scale and shifting it will make the clouds move at a different speed, and look like it is not the same texture.

The scale and XY shifting for this screenshot it:

Top Layer:

Scale X-2 Y-8.9

Shifting X-900 Y-150

Middle Layer:

Scale X-2 Y-8

Shifting X-450 Y-50

Bottom layer:

Scale X-2 Y-7

Shifting X-0 Y-240

That should just about do it! Here is what the finished thing looks like from different angles.

[nggallery id=10]

We’ve all seen those grass details on various maps and wanted them to be on our maps as well. Good new! You’re going to learn something today, how to create a sprite card, and make all the necessary items to make this work.

I've pixleated it a bit so you guys cannot steal this image, sorry.

Lets go over what you’ll need for this:

• Hammer Editor
• VTFedit
• NotePad++ (Not needed, but recommended)
• Photoshop (GIMP should work, but I don’t know how to use it all that well. NOTE: I will NOT be supporting any questions about using GIMP for this.)
• Common knowledge, and about 45% of a normal sized human brain.

Well lets get started, you’ll need to make a sprite card for you to use. I’ve already gotten my hands on one from Dark Artz Entertainment, thanks for the image guys.

There are a couple rules whilst creating this image that MUST be followed.

• It must be a square image, unless you are shipping your own mode and have access to code. (EX: 512×512, 256×256, 1024×1024)
• There must be at least one pixel between each item you a have on the card.
• Place your items on a grid like formation, like I have on mine.
• Make sure to have the image be transparent
• Gradient fade out the bottom of each item using the alpha channel. (See the black and white image, that is the alpha channel for the image.)

Now we will create the VMT for the sprite card. I’ve already done the heavy lifting, so I’ll just give you guys the code. Place the VTF and VMT into “materials/detail” and use the following:

UnlitGeneric
{
$translucent 1
$baseTexture "detail[VTF NAME]"
$nocull 1
$vertexcolor 1
$vertexalpha 1
$receiveflashlight 1
$singlepassflashlight 1
}

That will do it for the VMT side of things.

Next we will set up the detail.vbsp file that will define the rules for placing these props. I heavily recommend using NotePad++ for this part, because it shows you what brackets are connected. Start by creating a new text file in the root directory of your game. (EX: for counter strike source the path would be, steam/steamapps/youraccount/Counter-Strike Source/cstrike/detail.vbsp) Name the file mydetail.vbsp, the default name is “detail.vbsp” if used it will be used over the stock one. You can name it what ever you want though.

Add the following to the newly created VBSP file:

detail
{
	Detailtype
	{
		density [float]

		Group#
		{
			alpha [0-1]

			Model
			{
				[settings]
			}
		}
	}
}

Now let me clear up some of these things for you guys, it’s all pretty simple after you know what you’re looking at!

Where it says “Detailtype” this is what you would name the group you are about to create. So I’m going to walk you through placing some simple grass sprites on the level, I’m going to use “Grass_Green_lvl1″

Density is how thick the sprites are placed, a good starting value is 1500. For you tech specific people, here is the formula for how often they are placed: surface area * density * 0.000001 (density 1000000 means one detail prop per unit. Values of 1000 to 1500 are generally used.) So lets use 1500 for this.

Group# is what group you are telling it to place props in, you can have many groups in the same detailtype.

Alpha is a value 0-1, where it is the alpha on the displacement that the detail is being applied on. So say you have a grass texture, and a dirt texture on the same displacement. So you can have different sprites depending on the alpha.

For model you can put almost anything. I name them Model1, Model2, Model3, ect.. and then drop comments next to them saying what they are. (EX: Model1 //GrassSprite1, top left)

Settings is where stuff gets kinda hairy… Once again I’ll try to make this as painless as can I can. I’ve put the most commonly used settings in example, and commented out what each one does. For more information on what does what, and more commands visit the VDC at: http://developer.valvesoftware.com/wiki/Detail_props

So where “[settings]” is paste the following:

"sprite_shape"		"tri" // you have 2 choices: "tri" and "cross" Comment out this line for 1 sprite
"sprite" 		"0 0 256 256 512" //start at 0,0...256,256 is size of box in material, 512 is material size. (0 0 is the pixle starting from the top left. 256 256 is its size from the starting point.)
"spritesize"		"0.5 0 5 5" //The origin (U/V) and size in units (W/H) of the sprite when it is in the world.
"spriterandomscale"	"0.2" //randomness of sprite sizes
"amount" 		"0.05" //The proportion of the group that this model (or sprite) will account for. If the amount values of a group add up to less than 1, fewer detail props will be emitted than specified by density.
"detailOrientation" 	"0" //1 faces player. 0 would not rotate. 2 faces camera.
"shape_angle"		"20" //degrees of tip/flare, TRI SHAPE ONLY
"shape_size"		"0" //0-1 percent of sprite width to separate each leaf, TRI SHAPE ONLY (Percentage of the sprites' width to put between them and the centre of the triangle. 0 means that the sprites cross at the prop's origin.)
"sway"			"0.2" //0-1. 0 doesn't sway much, 1 sways a lot

I’ve found that these are some really good starting values for your own stuff. So read the commented out parts, they will tell you EXACTLY what each thing does in a quick sentence or two. But I’ll go over some of the more important here.

Sprite is what image it will display. It took me a bit to figure out how to make this work correctly. I’ll show you the easiest way to locate the values for this. Start by opening the image in Photoshop, and enable the “Info” window (Hotkey F8). Once enabled you should see something like this:

Now you’ll want to use guides to block in the sprite you want the XY values for, it’s best to do this on the alpha

channel. To make a guide, click on the ruler and drag down onto your image. Next right click on the ruler and set it to Pixels. Now zoom in and place your cursor on the top left pixel that you have boxed out, you’ll see the XY value change on the info box. Use those two numbers for the first 2 numbers on the “sprite” setting. So now we have: “Sprite” “1 15 256 256 512″

Now you’ll need to find the exact size of your sprite, use the marquee tool to find this. Make the marquee box around your sprite

like if you were going to cut it out of the image. After that selection has been made the info box will show the total amount of pixels you have selected. Put these numbers in where we have 256 256. So now we have: ”Sprite” “1 15 253 113 512″

Now that we have that done, we can move onto ”spritesize” “0.5 0 5 5″ the first number is how high the sprite is raised up from the ground, 0.5 is a pretty good starting value. The last 2 numbers are its size in the world after placed in X Y. I start with 5 5 and then mess with it from there.

After some hard work I’ve created this:

detail
{
	Grass_Green_lvl1 // To use this set your detail sprites to: Level1_sheet
	{
		density 1500
		Group1
		{
			"alpha" "0"
			Model1 //GrassSprite1, top left
			{
				"sprite_shape"		"tri"
				"sprite" 		"0 0 259 125 512"
				"spritesize"		"0.9 0 40 20"
				"spriterandomscale"	"0.2"
				"amount" 		"0.3"
				"detailOrientation" 	"0"
				"shape_angle"		"12"
				"shape_size"		".1"
				"sway"			"0.2"
			}
			Model2 //GrassSprite2, 2nd from top
			{
				"sprite_shape"		"tri"
				"sprite" 		"0 128 259 128 512"
				"spritesize"		"0.9 0 40 20"
				"spriterandomscale"	"0.2"
				"amount" 		"0.3"
				"detailOrientation" 	"0"
				"shape_angle"		"12"
				"shape_size"		".1"
				"sway"			"0.2"
			}
			Model3 // Middle, 2nd from top
			{
				//"sprite_shape"		"tri"
				"sprite" 		"226 136 107 109 512"
				"spritesize"		"0.8 0 12 12"
				"spriterandomscale"	"0.4"
				"amount" 		"0.2"
				"detailOrientation" 	"0"
				//"shape_angle"		"12"
				//"shape_size"		".8"
				"sway"			"0.1"
			}
		}
		Group4
		{
			"alpha" "0.3"
		}
	}
}

With these settings you will get results like this:

Now to apply this to a texture just open the VMT for that texture and add this: ”%detailtype” “Grass_Green_lvl1″ (Replace ”Grass_Green_lvl1″ with your detailtype)

EXAMPLE:
"WorldVertexTransition"
{
	"$basetexture" "RealWorldTextures2/Ground/grass_06"
	"$basetexture2" "RealWorldTextures2/Ground/dirt_01"
	"$bumpmap" "RealWorldTextures2/Ground/sand_12_nrm"
	"$bumpmap2" "RealWorldTextures2/Ground/dirt_03_nrm"
	"$surfaceprop" "Grass"
	"%detailtype" "Grass_Green_lvl1"
}

And that just about wraps it up. You’ve just created your very own detail sprites!!! Hope this helped you guys with something super simple, that looks really advanced!

You also have to tell Hammer to use these textures, and VBSP file. To do so just go to map>map properties and give it the correct names for the VBSP file and the sprite card

Any questions comments or improvements are always welcome.

As many of you know, I’m a stickler for lighting. In this guide I’ll show you guys some tips and tricks to the entities, indoor, and outdoor lighting. Please realize that this is not a video because this is a reference for lighting.

Also, this guide will be ever changing, so if I missed something let me know and I’ll add it.

VRAD

VRAD is the command-line tool that takes a compiled BSP map and embeds lighting data into it. VRAD’s static and pre-compiled light is bounced around the world with a radiosity algorithm.

VRAD will:

• Generate lightmaps

• Generate ambient samples
• Generate per-object or per-vertex prop_static and detail prop lighting

VRAD is the generally the slowest of the three compilers due to the many, many calculations it must perform. Lighting optimization can help, as can ensuring your map is free of leaks

Basic Lighting Tips

Tip 1. Placing a standard light entity is rather simple, but the most common mistake is placing it too close to the model. In real life the light is projected from the bulb, but this is not how it works in source engine. No matter how bright a light is when placed too close to a brush will give a rather unsightly bright circle. The light is actually projected from the center of the entity, the small “X” in the middle. All you need to do is pull the entity away from the brush. Both lights have the same brightness of 150. You can see the difference in the screenshot.

Tip 2. The colors of the lights are important to the feel, and mood of a area. This is quite some reading you can do on this. Here are the links.

VDC: Color temperature

VDC: Lighting psychology

TL:DR, A light is almost NEVER solid white, this is why I get a bit angry when I see a 255 255 255 200 light. (All light in source engine is colored in Red Green Blue Intensity)

The lighting psychology is a good things to read, it will allow you get inside of the players head to keep the feel you want. Here are some basic things that you should know to get you started.

Most lights will remain from a red, to a blue. Most lights lights in the real world produce a warm yellow glow. You will see me mostly use a yellow glow in my maps. The light settings for the first picture is: 255 239 202 150

• Yellow/Green – When a player stumbles upon a room lit by yellow lighting, it automatically makes them feel either accomplished, content, or comfortable, depending on the situation. Also a very stealthy color. Makes the player more aware, and more careful. It also gives the environment a living, breathing quality.
• Blue/Purple – The color of sadness. Blue rooms seem very full of memory. It’s the opposite of yellow, so it’s a good way to make players slow down and think. It can also cause players to second guess, so be careful.
• Red/Orange – Using red will make players feel like they need to do things quickly. Almost like the place is “gonna blow.” Putting enemies in the way of the escape only helps exaggerate the suspense of the situation.
• White/Brightness – White doesn’t really make the player think much. Normally just makes the player focus on the job that needs to be done and not much else. If you want to make a good map, use white when NPCs are talking or telling a story. Players will focus more on the talking than the unimpressive background.
• Black/Darkness – Gives a large sense of uncertainty and insecurity. Good for scary maps. If you use this, don’t use it too much because, like white, it’s not meant for fun. When a player has just finished a completely dark portion of the map, make sure that when they ascend, they see something really bright and cool for a sense of accomplishment and contrast.

Tip 3. The brightness, or intensity, can help set the mood almost as much as color. This is a shot of the same light, with 4 different brightness settings.

Tip 4. NEVER name a light unless you need to. Giving a light entity a targetname makes VRAD compile a second lightmap “page” for the surfaces that its emitted light touches. This won’t harm in-game performance, but it will increase compile time and BSP filesize, regardless of whether the light ever receives input to change its state.

However, the system can be overloaded if you try to make it handle a large number of overlapping named lights (since the number of pages needed increases exponentially). When this happens performance can be harmed and you may well see lighting anomalies.

VRAD attempts to avoid this with its hard-coded limits of two switchable lights affecting a brush face and 32 pages in total. You can help too by giving lights that will always change state at the same time a shared targetname, which makes VRAD merge their pages together.

The Light Entity

How the light entity projects light

“A static, invisible, omni-directional light source. Can be turned on and off through the I/O system (note that this will increase the complexity of your lightmaps, as pre-compiled values must be stored for each on/off combination and cost more memory). Able to set up with patterns given effects but cannot move locations. Light is cast in all directions from the origin of the entity. The brightness depends upon the falloff values you set up. This light entity is the simplest of all lights and is used commonly.

While light travels from its source, it usually diminishes in intensity, limiting the area that its source can illuminate. This diminishing is called “light attenuation” or “fall-off.“

- Valve Developer Community

The Light_Spot Entity

How the standard light_spot projects light

The light_spot is a very versatile form of lighting. Although it is typically use to direct light in a cone shape, it can be changed depending on your need.

When the light_spot is first placed you will see a cone displayed from it, this shows the path that the light will take. This is rather simple to set up, but

can also be used to create a florescent light. This is more favorable option over the light entity.

There is a inner, and outer angle. This allows you to change how the light_spot displays light. In the screenshot you see a cone, this has been changed to give use the florescent light feel. These are the settings used for light_spots in the picture to the left.

1. Just a light entity, With the brightness of: 255 227 187 600

2. light_spot, with the brightness of: 255 227 187 600 inner angle:50 outer angle:90

3. Light_spot, with brightness of: 255 227 187 300 inner angle:50 outer angle:90. AND a light with the brightness of: 255 227 187 15, and a ratio of 0:1:0 (you will learn about this ratio

below.)

Advanced Lighting Settings

There are many things that can be done to further make the lighting in your map look real. This is done with the Constant-Linear-Quadratic Falloff. These are how the light is projected. The lights is stock set to 100% Quadratic. (Constant:0 Linear:0 Quadratic:1 (0:0:1)) Keep in mind that this is ALOT of information to take in, that is one reason this is not a video. you can re-read things easier then re-watching.

The information below if straight from the VDC, please read it.

Constant Attenuation - The picture on the right shows a lightsource displaying the simplest of attenuations: Constant attenuation. The keyvalues Constant, Linear and Quadratic have here been set to “1″, “0″ and “0″ respectively, creating a Constant-Linear-Quadratic ratio of 1:0:0, meaning that the attenuation is 100% Constant, 0% Linear, and 0% Quadratic.

The 100% constant attenuation will result in a light that has no attenuation at all. The intensity, represented by the brigtness setting of the light entity, will be totally unaffected by distance, continuing until it hits a surface, theoretically capable of illuminating an infinite area. This type of light can be seen from the sky (sunlight, monlight and starlight), and other large and distant light sources. It can also be used for setting local ambient lighting (by letting it illuminate the shadows of the room) or mood lighting.

As a 100% constant lightsource is an extreme type of light, constant light is mostly used in combination with the other two types of attenuations, to “soften” or limit them.

Linear Attenuation - This is the same light entity, but at a 0:1:0 ratio, making its lighting 100% linear instead.

Mathematically, the decline of this type of light is linear, inversely proportial to the distance from the light source (I = 1/d where I is intensity and d is distance). This means that the light intensity (set by its brightness) will diminish (at a fixed rate) as it travels from its source. To compensate for this decline, Valve has boosted the intensity of the lightsource to 100 times its brightness.

In the real world a 100% linear lightsource would be practically impossible, as it would represent a real world soft light of infinite size, but in the virtual world, a 0:1:0 lightsource is believable for most entity based lightsources.

Quadratic Attenuation - This is a normal, unmodified light source, preset to 0:0:1, making it 100% Quadratic.

Mathematically, the attenuation of a 100% quadratic light is exponential (quadratic), expressed as “I = 1/d^2″, meaning that the further the light travels from its source, the more it will be diminished. This creates a very sharp drop in light. To compensate for the fast decline of quadratic lights, Valve has boosted the intensity of them to be 100^2 (10 000) times more intense than the actual intensity.

An unmodified (100% quadratic) lightsource represents a pure “point light source” in the real world. In the virtual world, this effect looks like a lightsource shining through murky water, looking far from typical real world lightsource behavior.

When used in moderation, quadratic attenuation can be used not only for small lightsources, but also to reflect light travelling through something more dispersing than air, like air humidity (like fog) or water.

Mixing Attenuation - When blending between these three types of attenuation, you set the proportions of each attenuation type against the other two types. To avoid confusion, keep in mind that you can set the scale of these proportions as you wish: A proportion of 3:6:1 gives the exact same result as 6:12:2, or 30:60:10, which can easily be translated to 30%, 60% and 10%.

Although the Constant-Linear-Quadratic Falloff is a very good way to fine tune the projection of the lighting in your level, this can be very confusing. You can still tune the lighting using the falloff distance.

50/0 percent falloff distance

This is, in theory, the same as the information listed above, but you have a little less control. But it’s easier to set up, just set the numbers and go.

50 percent falloff distance: What ever you set this to the light will dissipate down to 50% by this distance. Same for the 0%.

As you can see from the screenshots above and below, the falloff gives you almost the same effect you would get with the Constant-Linear-Quadratic Falloff. All of the lights in the picture here use these settings: 255 239 202 200

The dynamic lights and shadows

Then env_projected texture is a special entity that can project light, and dynamic shadows of the receivers.

As you can see here it projects a texture and draws the dynamic shadows. This gives us a very erry feeling that can be frightful if seen from the corner of your eye. If you do not give it a texture it will just display a color that you tell it to. Any light projected from this will NOT be bounced like other lights compiled with VRAD are.

The light_environment

This is a entity that projects the light from the “Tools/Skybox” texture. When creating part of your level that uses a outside area you should use this. This, used in combo with, env_sun gives you the good feel of the sun. The env_sun just displays a sprite, where the light_environment actually displays the light. To set this light up just give it a angle and some color. You should only have 1 light_environment in a level.

Glows, and beams for lights

There are things you can add to your level that will produce a glow effect from the source of the entity. These entities are Env_Sprites, and point_spotlights.

Env_Sprites are typically used for a normal light glow, they are defaulted to be circle light glows, but can be changed to any sprite.

First to create a env_sprite, just create it. Then send the render mode to “World Space Glow.” This will allow the sprite to render in game (See Render Modes for details) Then set your color and FX amount. This will tone down, or intensity the effect of the sprite. For a florescent light set the FX amount to around 140ish.

Point_spotlights are used to create a light beam from the source, and a blinding effect when looked at straight on. These are even easier to set up then the env_sprite. Just create one and point it. Under the flags of the point_spotlight there is a flag that will enable the dynamic light for this. This effect is very expensive to render and should not be used alot.

Lightmaps

A lightmap is the lighting data of each face. The stored light is then added to the face giving it brightness. The lightmap’s scale refers to the number of texture pixels per light pixel (luxel). Smaller values mean more luxels, thus a better quality but larger BSP size and compile times. The first image with the finest shadows has a lightmap scale of 4, the 2nd image is 16, and the 3rd image is 64. To change the lightmap scale just open the face edit sheet and lower the value. This value should remain a power of 2 between 2 and 64. (2,4,8,16,32,64) When settings a lightmap scale, set it to the receiving face, not the casting. To view your light map grid int he 3D view, click on “Camera” on the 3d view and select “3D Lightmap Grid”

info_lighting

This is an entity used to specify the origin from which another entity is lit. Sometimes due to drastic changes in light over short distances or complex shadows a model can appear to be lit incorrectly. By using this entity the model will be lit as though it were stationed at this location.

One common example is the HL2 static Ladder props; when used in dark areas they may appear to glow, which can be corrected by inserting an info_lighting, naming it and specifying that name in the properties for the Ladder prop.

Tonemap and HDR lighting

HDR lighting gives your map a whole new feel of realism with lighting. It stands for High Dynamic Range Lighting, basically. It makes things glow as they would in real life. When you go from a dark tunnel, to a bright outside environment you are basically blinded. Just like if you wake up at noon and look outside. But the HDR is not always good to right after a compile, it is often too bright, or dark. To fine tune this you need a env_tonemap_controller. Just add it to a map, then name it “tonemap” Next load the game. Fire this console command:

• ent_fire tonemap setautoexposuremax #
• ent_fire tonemap setautoexposuremin #
• ent_fire tonemap SetBloomScale # (Bloom ONLY)

For the numbers on the max, I like to start with 6 and go from there. Then set the min to about .75 and go from there. Then write these numbers down once you are happy with them. You may not notice anything happen when you change the bloom scale, this is because HDR is on, and not bloom. Basically just take the low average of the max and min. So if max=4 min=.5 set the bloom to about 1.5. Then create a logic_auto in your level and add the following outputs:

• “onmapspawn” tonemap,setautoexposuremax,#,0.00,-1
• “onmapspawn” tonemap,setautoexposuremin,#,0.00,-1
• “onmapspawn” tonemap,SetBloomScale ,#,0.00,-1

Make sure to compile your map with HDR to see the results.

Smoothing Groups

Used to smooth lighting between faces. Found in the face edit dialog, the groups allow the lighting of a face to be smoothed between other faces, to produce rounded effects with lighting. A classic example is when making a cylinder: If no smoothing groups are set, each face on the brush will catch light separately and will be lit separately. This will create a very obvious effect of separate each face. If they are all placed in the same smoothing group the light will be blurred between the faces creating a much smoother rounder look on the pillar. Tip:Smoothing groups have no affect on performance, apart from adding extra time for RAD to compile, so use them on your final compile.

Compile Settings

-staticproppolys

-textureshadows

-staticproplighting

[nggallery id=4]

Limits

There are alot of limits that the source engine has limits on. I’ll list all of the limits I know about below (lighting limits only.)

• One environment in a given level. Only the first one will work. Having more then  one in a level may cause errors.
• Any given brush can have a max of 4 different light styles on it. Having more will cause lighting errors.
  • Lights styles are different types of light colors, not brightness.
  • EX of 5 different lights styles: 255 255 0 200, 0 255 255 200, 255 0 255 200, 128 128 128 200, 0 128 255 200
  • EX of 6 different lights, but not different styles. 255 255 0 100, 255 255 0 300, 0 255 255 600, 0 255 255 150, 128 128 128 100, 128 128 128 1200. This will not cause errors, because there are only 3 different styles. The brightness does not effect a style.
• The brightness of a light must to positive, if not it will suck the light from your map. Or cause errors.
• 32 Light map pages, when naming lights that would share a face. Name them the same.