Half-Life Wiki
Advertisement
Half-Life Wiki
This subject is in the Real world.
Wiki cleanup This article has yet to be cleaned up to a higher standard of quality.
You can help by correcting spelling and grammar, removing factual errors, rewriting sections to ensure they are clear and concise, and moving some elements when appropriate. Visit our Cleanup Project for more details and, please, notify the administrators before removing this template.

Valve Hammer Editor, formerly known as Worldcraft and now commonly called Hammer, is Valve Software's map creation program for their game engine, Source. Old versions of Worldcraft also supported Quake and Quake II. Versions prior to 4 supported exclusively Goldsrc, Source's predecessor. The current version only supports Source. It is freely available to anyone who has purchased a Source based game as a part of the Source SDK.

Level design with Hammer

Prior to the release of Source, Hammer used only brushes (blocks) called primitives. Sets of simpler primitives can be used in older GoldSrc games. However, some features of version 4 and above, such as displacement maps, are not compatible with GoldSrc. Many level designers who work with both Source and GoldSrc games usually keep an install of 3.5 to avoid using unsupported features in a GoldSrc game.

Files and compiling

Valve Hammer Editor version 4.0 saves a level file in the .vmf format by default. Before this, it saved a level file in the binary, proprietary .rmf or text-based, human-readable .map format. The .vmf format is a simple file that contains all the information about a level. It originated because of Half-Life's reliance on the Quake engine, and has remained as a result. Valve includes compiling tools with the Source SDK - vbsp, vvis, and vrad. The following list is largely true for both formats, but is intended as a reference for Source levels.

  • First, a level is passed through the bsp program. This program uses the brushes to create the architecture of the level. It also places all entities where they should go based on the level design file (.vmf file). This program writes the initial .bsp (Binary space partitioning) file.
  • Second, the level passes through the vis (Visible Information Set) processor, which determines what polygons are rendered and what lights appear where. Since the Source engine uses portal based rendering to determine what is visible at any given time, this program creates the portals by dividing the map into convex regions with visibility data, like Quake-based engines do at a per-polygon level.
  • Finally, the level passes through the rad program. This program computes the lighting of the map, including pseudo-radiosity for Source maps, resulting in more natural-looking lighting. If there is a leak in the level, only standard lighting will be computed - radiosity will not be simulated, resulting in faker/harsher lighting. If the mapper doesn't run the rad application, the level will appear as full-bright (without static shadows or lighting of any kind, with every texture being fully lit.) If the level designer decides to compile the map with HDR lighting enabled, the level must pass through an additional stage of rad compiling- one stage to calculate normal (LDR) lighting, and a second stage for calculating HDR lighting.
  • With earlier versions of VHE (up to 3.5) and games for the GoldSource engine, there were four steps in the compilation. BSP is preceded by CSG (constructive solid geometry), which parses the brushes, places entities, indexes textures, and sets up the general framework of the level for the BSP pass which generally only performed space partitioning. In the Source engine and VHE 4.0, Hammer stores the files in a CSG format, rather than vertex based, and lets the BSP tool handle all the entity placement tasks, so the CSG process has effectively been merged into BSP.

External links

Advertisement