| Author: iko (webdeveloper) |
[An original that has been tempered with]
Changes made by iko are in Red.
Using Valve Hammer to build structures for the Torque engine
Valve Hammer is a level editing tool released for free by Valve Software. It has proven itself to be a powerful and flexible editor for many years. Its capability to use many different game definition files has made it extremely useful to game development teams without the time to build their own level editing tools. Also, with the release of version 3.x the texture application and alignment tools are second to none.
For those used to editors like UnrealEd by Epic Games, Valve Hammer will take a little getting used to. Instead of viewing the world as a large block which the level must be carved out of, Valve Hammer starts with empty space and all brushes must be added into it. However, the tutorials included with Valve Hammer are excellent and will make the transition painless.
The clean design and simple nature of Valve Hammer will allow you to quickly become comfortable with this tool. Before you know it, your biggest concern will be coming up with structures to design!
Download Valve Hammer and install it.
Make sure you have the latest torque.fgd file -- this should be located in the torque/tools/map2dif directory. This is the game definition file that defines the Torque entities for Valve Hammer.
Make sure you have at least one wad file: either a precomiled one from somewhere (torque/example/fps/data/interiors/evil1/textures.wad) or create one yourself with the buildWad tool.
Make sure you have a copy of the map2dif tool's executable. Copy this into your root Torque directory (ex: C:\GarageGames\torque\example). You will use this to compile the .map files generated by Valve Hammer into the .dif files the Torque engine uses.
Step 1: From the Tools menu, popup the Options dialog. Select the dialog's Game Configurations tab. Press the top right Edit button. Press the Add button. Type in the name for this configuration (such as Torque) and return to the options dialog.
Step 2: Now that you have a Torque configuration, you need to load the Torque game data file. Immediatly underneath the Configuration drop down are the Game Data files. Press the Add button on the left and browse for the torque.fgd file located in the torque/tools/map2dif dir. Map2dif is the tool which converts Valve Hammer .map files into the .dif files used by the Torque engine.
Step 3: Select the Default PointEntity class and the Default SolidEntity class. It is recommended that you set these to light_omni and portal since these are the classes you are going to be using most often.
Step 4: Point the RMF Directory to where you will be compiling the maps from (ex: C:\GarageGames\torque\example\fps\data\interiors\evil1\maps). This will save you from having to browse to this directory everytime you export a .map file.
Step 5: Select the Build Programs tab. Select the Torque Configuration that you just created. Point the CSG< executable to map2dif.exe (ex: C:\GarageGames\torque\tools\map2dif.exe).
Step 6: You now need to load a set of textures to work with. Textures are packed into .wad files. If you don't have a wad file, you can build one using the Torque Evil1 texture set: from the dos prompt cd into the torque/example/fps/data/interiors directory and run the following command buildWad evil1 evil1/textures.wad. (The buildWad program must be in your search path, see the buildWad documentation for more information on this tool) To load the Torque test texture wad select the Textures tab on the options dialog, press the AddWAD button and browse for the torque/example/fps/data/interiors/evil1/textures.wad
You are now ready to edit a map!
The Torque default directory structure for map shapes is as follows:
modName/interiors/textureSet (location of textures and the .wad) modName/interiors/textureSet/maps (location of the .map and .dif files) modName/interiors/textureSet/moreMaps (can have more than one map dir)
Be sure to either Export to map or Save As a .map before using map2dif
Map2dif is the utility program that converts .map files into the .dif used by the Torque engine. Map2dif performs 3 major operations:
After you have exported or saved your map to a .map file, press F9 to bring up the Run Map dialog box. (If you haven't saved this file before you will be presented with the save dialog box before you can continue.) Press the Expert button to switch to the advanced the dialog box. Top left will be Configurations press the Edit button and create a new Torque configuration. Next press the New button to add a new command, which will be blank to start with. From the upper right side select the Cmds button (this is actually a drop-down), select CSG Progam from the drop down. Below this is the Parameters box cut and past the following into the edit box:
$path\$file.$ext
This set of options assumes that you will be saving your maps into an immediate subdirectory of the texture pack's root dir.
The command in the Compile/run commands box should look like this
$csg_exe $path\$file.$ext
Make sure the checkbox is checked. Pressing the Go! should compile the map.
Each Valve Hammer file you create can have unique "map properties". However there are a couple of values you will probably want to keep consistent in all of your maps. You may have to do this step each time you create a shape. To set these values launch Valve Hammer. Create a new map via the "File" menu. Under the "Map" menu you will find "Map Properties". Select this to bring up the dialog box. Look for "Geometry Scale" and make certain that the value here is "32.0" This value determines how many Valve Hammer measurement units are equal to 1 meter. Also you will want to make certain the "Lighting scale (must be a power of 2)" is set to "32.0" This value determines the sampling frequency of the light maps generated when you process your shape. "32.0" here means that there will be one light sample for each meter in your processed shape. You can use other values here as long as they are powers of 2. Changing this to smaller numbers creates a higher sampling frequency and larger light map sizes. Generally I would suggest leaving this at "32.0". Also in this dialog box are controls for controlling various aspects concerning level of detail settings. These will be described more in depth later in this document. More aspects of this dialog control the ambient light color, and emergency ambient color. These values in RGB (0-255) describe the ambient light color of this shape in regular and emergency lighting modes. Change these if you would like to add a bit of ambient light to your shapes.
After you have set up Valve Hammer it will be time to test the process to make certain everything is working correctly. Create a large cube. 1024x1024x256 tall would be perfect. Place the shape in the center of the 3d space. Change the texture if you would like. Save this shape as test.rmf or something similar. I have saved this as example1.rmf and it should be in this .zip file. This shape uses the badlands.wad file. When you have saved your shape hit the F9 key, or click on the "Run Map!(F9)" button. Click on the "Go!" button and the process should start. The shape will be passed through "morian.exe" and placed into a temporary mission where you can fly around and see your shape. If this doesn't work you will have to make certain that all of the details in the "Setting up …" sections of this document are implemented correctly.
After you successfully process your first shape it will be time to add a light entity. Select the entity tool, and place an entity above the center of your shape by hitting the return key. Select the light entity, the little pink cube. Open the edit properties dialog box (alt-enter while selected). Color is self explanatory, Alarm type sets under what lighting state the particular light will be active (normal or alarm, or both), falloff1 is the "hot spot" size, falloff2 is the size of the light until the color value is truncated to 0 0 0, or no light. Change the color if you would like. Make certain the light entity alarm type is set to "normal only". Set the falloff1 to 64, and falloff2 to 512. These measurements are in world space unit size so this will make a large light. To change the ambient light value open the "map properties" dialog box from the "map" menu. Select "ambient color" and change the value to 64 64 64. This will make the darkest parts of the shape appear to be lit at the value you just set, a dark gray. Note that all of the lights you will edit in Valve Hammer are additive. The light color you set will always be added to the ambient value set in the ambient color dialog box with one exception. Any lights on the exterior of a shape will be lit according to the ambient mission lighting. Interior vs. exterior faces are determined by the "portal zone" the faces exist in. I will describe portals and portal zones later in this document. From this dialog box you will also be able to set the "Emergency ambient color". Set the emergency ambient light at 16 16 16. Run your shape and check the results.
In the Torque engine there are two lighting states and light maps for any given Valve Hammer shape, normal and emergency modes. These two states of illumination are hooked into the mission by using the mission editor. I will not be covering mission editing in this document. Generally normal mode is when the power to a shape is on, and emergency mode is when the power is off (as in destroyed generators). Create a copy of the big light you added to the simple scene (copy paste or shift drag). As a consistent rule I personally always place emergency mode lights directly a few units under the normal state of any copied light. This way I always know which is emergency vs. normal. Edit this entity (select the entity then alt+enter). Change the color to bright red (255 0 0 rgb). Set the alarm type to "Alarm Only". There is one more variation under the "Alarm Type" drop down menu. This is "Both normal and Alarm". This makes the light entity visible under both light states. One more note about light states. All animated lights can exist only in one state or the other, never both states. It is simple to make animated lights appear to exist in both states without changing the values. Simply copy the animated light and make one version "Normal Only" and the other "Alarm Only". The ambient light change between "Normal" and "Emergency" ambient values will effect animated lights but it will appear consistent other than that. See the included "example1.rmf" file to see this set up using the badlands.wad file.
Next we will look at a simple shape with a couple of hallways, a small room, and a few lights. We will look at portals and detail brushes. Open the shape "example2.rmf" which is included in this zip file. This shape uses the badlands.wad file. You may need to add this wad file to your active textures in Valve Hammer via the textures tab under the tools/options dialog box. You may also want to make certain you are using only the badlands.wad file for this example. You can work with more than one .wad file at a time but I have found that multiple wad files can create some odd problems in Valve Hammer's texture browser. First lets look at detail brushes. Detail brushes are used to reduce the number of polygons that are created when two brushes touch in Valve Hammer. Select one of the light fixtures at the entrances. Go to the tools menu and select "Tie to entity", then in the dialog box choose "detail" from the class drop down list. In the 2D views of Valve Hammer you may see the light fixture entity change color to show you have changed the nature of this brush. Detail brushes do not split faces when touching a normal world brush. For example the lights touching the walls in "example2.rmf" will cause the walls to split into several polygons unless they are designated as detail brushes. If the light fixtures are designated as detail brushes, the underlying wall polygon will not be split to accommodate the light fixtures. Using detail brushes can really cut down on your polygon count if used correctly. Detail polygons are not "seen" by bots. If you have a pillar in the middle of a large floor that is a detail brush, any bots you may use will not see the pillar and may produce some odd behavior. The portal creation process in morian.exe does not see detail brushes as world objects. Morian.exe will perceive any detail brushes that connect an outside face with an inside face as a hole in the shape and you will not be able to create a valid portal zone as described below.
Next we will take a look at "portal zones", and "portal brushes". Portal zones help control the number of visible polygons in a Valve Hammer generated shape from any given zone. A portal zone in a shape is created by placing portal brushes in the shape. At least two portal brushes must be in a shape to create a portal zone. Open "example2.rmf". You are going to change the bright pink brushes that cover the entrances in this shape into portal brushes. The bright pink color is the "null" texture. Faces with the "null" texture render as invisible in the Torque engine. Make certain your 3D view window is in "3D textured" mode. Look around the shape and locate a bright pink brush that is covering an entrance. Select the bright pink brush and "tie to entity". You can "tie to entity" from the tools menu or you can hit ctrl+t as the short cut. Select "portal" from the drop down menu. Here you can see an option to pass ambient light if you wish. For this example use "Does not pass through". Close the dialog box. Find the other thin pink brush and turn this into a portal brush. Next find a pink brush inside the shape that is much thicker than the other pink brushes. Select this brush and squish it until it is as thin as possible and still covers the interior doorway. The largest face of the portal brush will be used to determine where the portal starts or stops. Or morian.exe will randomly pick one face of the brush if there are two equal sized faces. Select the interior portal brush and "tie to entity", portal. Process your shape with the F9 key. Exterior faces exist in portal zone 0. Exterior faces are faces of your shape that exist outside of an interior portal zone. All faces that exist in portal zone 0 will receive ambient light as described by the mission editor. You can also control whether or not ambient light will pass through a portal brush by editing the properties of the portal brush in the edit properties dialog box. Polygons in a portal zone can exist in more than one portal zone. For example a hallway with several portal zones may have polygons that cross portal zone boundaries. Portal brushes should be as simple as possible. Portal brushes must be completely embedded on all sides by normal solid brushes. Portal brushes should not align exactly on the face of another solid world brush. Portal brushes do not recognize detail brushes as solid brushes, you cannot anchor a portal brush in a detail brush. The largest face of the portal brush will be used to determine where the portal starts or stops or it will randomly pick one face of the brush if there are two equal sized faces. This is why you will flatten your portal brushes to control where the portal zone begins and ends. You can use as many portal brushes as necessary for your shape. If a portal zone brush is not useful, morian.exe will simply ignore it and it should not hurt the performance of your shape. If you want to remove the portal properties of a shape you can use "move to world" to convert the portal brush into a normal world brush. The Torque engine will automatically perform back face culling to reduce the number of drawn polygons. This means any polygon face that is facing away from your viewpoint and cannot be seen will not be rendered.
Creating levels of detail for a shape is a way to reduce the number of rendered faces and vertices as your shape reduces its apparent size. The fewer the faces and vertices in a shape, the less the transformations the game engine will have to manage resulting in higher frames. The trick is to make these transitions as transparent as possible while reducing the total number of polygons and vertices in your shape. Morian.exe (the shape processing tool) looks for a specific naming convention to process all of the pieces of any given shape in the correct order and finally include all of the levels of detail into one final file that is displayed in the game engine. The naming convention is as follows:
*****_#.map
Morian uses only the .map format files. The .rmf files are a slightly more inclusive format that will save your grouping information, and vis group information. I primarily work with the .rmf format files to preserve my groups, and vis group information. When I am ready to process the entire group of LOD's for one shape I export the latest version of each LOD in a given shape to .map format via the file menu "export to .map". To set the LOD parameters for each level of detail in a shape you will have to access the "map properties" dialog box from the "Map" drop down. "Shape Detail Index" should be equal to the LOD value. "LOD_0.map" should have a "0" in this field. "LOD_1.map" should have a "1" in this field, and so on. "Minimum Pixels For Detail" sets the value for when the next LOD below the current LOD will be switched in the game engine. This value is based on the projected pixel height of the shape. If the value is set for 250 this means when the current shape is below 250 pixels high it will switch to the next lower LOD. The last LOD in any given shape should have a "minimum pixels for detail" of zero, however numbers higher than zero are acceptable. After you have created all of your LOD's and have properly established the parameters for the LOD switching you will have to export each separate LOD into .map format via the file menu "export to .map". Then when you process the highest order of detail shape the rest of your LOD's will be processed and incorporated into the final .dif. Morian.exe looks for up to 10 LOD's for any shape. It would take "LOD_0.map", "LOD_1.map", "LOD_2.map", and "LOD_3.map" and process them all into "LOD.dif". Portal zone brushes are valid in all levels of detail. There are several things to keep in mind while trying to minimize the appearance of LOD switching. Lighting can give away the change in LOD. Only eliminate lights that are not visible to the outside of you shape. If you have a strong light source in a doorway to the exterior of your shape, and that light suddenly disappears when you switch LOD it will be very noticeable and distracting to the player. When your shape gets smaller these changes will be less noticeable. Major geometry shifting or changes can also make for abrupt LOD changes. Keep major changes to a minimum until your shape is fairly small. Texture shifting on exterior faces can be another thing to watch out for when creating LOD's. I have included a series of shapes in this .zip file to illustrate the concept of switching LOD's. The shapes I have included are not necessarily designed to reduce polygon count, but to show how the concept works. These files are LOD_0.rmf and .map, LOD_1.rmf and .map, LOD_2.rmf and .map, and LOD_3.rmf and .map. These files use the badlands.wad as the texture source.
(there may be more entity information added at a future date)
Ai_special_node This is for helping bots navigate interiors. Place at tops and bottoms of Chutes, and other places where bots need some hints for navigation.
Light_emitter_point Used internally by morian. No need to place these entities.
light_pulse Name: not necessary but you can name this light if you would like Speed: how fast the light will switch between RGB values Alarm Type: Animated lights must be Normal only or Alarm only Color1(RGB): Color value one Color2(RGB): Color value two Falloff1: size of light at 100% RGB value Falloff2: distance to truncate RGB value to 0 0 0 (no light)
Light_emitter_omni Basic point light. RGB: color value Alarm Type: Alarm mode setting. Normal only, alarm only, or both Falloff1: size of hot spot for light Falloff2: distance of falloff for light to be truncated to RGB 0 0 0
Please note that animated lights can cause some performance degradation due to the manipulation of light maps. Multiple animated lights that overlap will be very processor intensive. Animated lights on surfaces visible from the exterior of your shape should be kept to a minimum to avoid performance degradation.