Building a Map for the Virtual Lab

  1. Valve Hammer Editor, found at
  2. Adobe Premiere, found at
  1. Create your scene in the Valve Hammer Editor.

  2. Open Hammer.

  3. Design the map as you wish.
    Consult the Valve Hammer Editor documentation for information on configuring Hammer and designing maps.

  4. Build the Map:
    Building a map is the process of converting its data from a ".map" format to a ".bsp" format. Building a map requires the map's ".map" file, all the associated ".wad" files containing all the textures used by the map, and a set of build tools. You can build your map using one of two different methods. You can either build a map from inside of the Valve Hammer Editor, or you can build a map using command-line-based programs.
    • Building a map using the Valve Hammer Editor:
      • Open the "File" menu and choose "Run". A window will appear entitled "Run Map."
      • Beneath "Run CSG" select "Normal".
      • Beneath "Run BSP" select "Normal".
      • Beneath "Run VIS" select "Normal".
      • Beneath "Run RAD" select "No".
      • Check the box entitled "Don't run the game"
      • Click "OK".
      If building the map using these means fails then try following the steps listed under 'Building a map using the ZHLT build utilities':
    • Building a map using the ZHLT build utilities:
      • download the ZHLT map building utilities from
      • ensure that the right ".wad" files are on your local computer
      • ensure the "wad" line in the map header points to the right set of files
        it should look something like this:
        "wad" "\build\src\map\halflife.wad;\build\src\map\wave_mod.wad"
        with whatever ".wad" files listed on the right side, separated by semicolons
      • run the utilities (see the build.bat file)
        1. hlcsg infile
        2. hlbsp infile
        3. hlvis infile
        4. hlrad infile
        NOTICE for all these utilities, when you add the "infile" as a command-line argument, OMIT the ".bsp" suffix
      • you can exclude hlrad since radiosity calculations are timely AND we never use the resultant computed lightmaps anyways.
      • you DO however want to use hlvis. it will remove any polygons of surfaces that can not ever possibly be seen from users viewing the map from the inside. This cuts down incredibly on our rendering and size costs.
      • hlvis will only work if
        • you place an "info_player_start" somewhere in the map
        • the map has no "leaks" - i.e. if the map started filling up with water from wherever the "info_player_start" is located, none of it would leak out of the map
        NOTICE here - almost all our model segments are not 'leak' free due to openings where two segments will connect as a result, within the conversion utility, i added a special feature so that any texture entitled "aaatrigger" (an ugly HalfLife texture) will be removed in the conversion process This allows for map designers to plug the leaks in their maps for the sake of hlvis without the plugs they used ever appearing in the final version.

  5. by this point you should have a BSP file
    • FROM A UNIX SYSTEM run by bsp2obj.c utility:
          bsp2obj infile [-nonormal]
      NOTE - you must omit the ".bsp" suffix for the incoming file, 'infile,' just as you did with the hlcsg/hlbsp/hlvis/hlrad utilties

      This will create five files:
      • infile.v    (vertices)
      • infile.vt    (texture coordinates)
      •    (normals. this'll be omitted if you specify "-nonormal")
      • infile.f    (faces)
      • infile.mtl    (materials)
      The final .obj file is formed as a concatenation of the first four, in the order they are listed
      (omit the vertex normal file if you used the "-nonormal" option). This can be accomplished using the UNIX command:
          cat infile.v infile.vt infile.f > infile.obj
      or for people who chose to use "-nonormal"
          cat infile.v infile.vt infile.f > infile.obj
    • now you have your infile.obj and your infile.mtl files. These are the important ones. You are good to go. However the BSP2OBJ utility only directly converts the format from BSP to OBJ and does not stop to optimize the file for reading. If you would like to optimize the file run the objopt.c utiltiy:
          objopt infile.obj > infile.opt.obj
      NOTE - this utility DOES NEED the .obj extension on the incoming file
      The file pipes the optimized obj file into the "infile.opt.obj"
      Optimizations include: removing repetitive vertex, texture coordinate, and normal entries
      Other things this application can do:
      • translate your obj file:
        objopt infile translate x y z > infile.opt.obj
      • rotate your obj file:
        objopt infile rotate degrees x y z > infile.opt.obj
      • scale the obj file
        objopt infile scale x y z > infile.opt.obj
      • flip the obj file faces
        objopt infile flip > infile.opt.obj
      • triangulate the obj file
        objopt infile triangulate > infile.opt.obj
      • output the radius of the obj file's bounding sphere (centered about <0,0,0>)
        objopt infile radius
      • output the bounding box of the obj file:
        objopt infile bounds
      The utility can only perform one of these options at a time.
      For subsequent operations you gotta execute the program upon a file multiple times.
    • now that you have your optimized OBJ file and MTL file, place the two in the same folder somewhere that the VWRL can access them.