Procedure to Build a Map for the Virtual Wave Research Lab

Prerequisites:

Valve Hammer Editor, found at http://collective.valve-erc.com/index.php?go=hammer
Adobe Premiere, found at http://www.adobe.com/products/premiere/main.html

Process:

Create your scene in the Valve Hammer Editor.
- Open Hammer.
- Design the map as you wish.
  Consult the Valve Hammer Editor documentation for information on configuring Hammer and designing maps.
- 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 http://collective.valve-erc.com
    - 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.
by this point you should have a BSP file

FROM A UNIX SYSTEM run by bsp2obj.c utility:

bsp2obj infile [-nonormal]

NOTICE 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)
- infile.vn (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 infile.vn vertex normal file if you used the "-nonormal" option)

This can be accomplished using the UNIX command:

cat infile.v infile.vt infile.vn 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
  
  NOTICE - 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 repetative 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.