Welcome, Guest! Login | Register

Half-Life Compilers [Print this Article]
Posted by: Anubis
Date posted: May 12 2003
User Rating: N/A
Number of views: 4442
Number of comments: 0
Description:
From the Staff
This Tutorial was ORIGINALLY Written by Campaignjunkie and the original article can be found at The SnarkPit
Campaignjunkie I must officially appologize for this being posted without your consent.

Somewhat Detailed Explanation of Half-Life Compiling Tools And/Or Techniques

I am no expert on the technical side of mapping; this is only my general knowledge on the subject. Chances are a good amount of this might be wrong, or a good amount of this might be right. If there are inaccurate parts, feel free to PM me, noting corrections. Thanks.

Compiling Process: Overview-----
Your editor (most likely Worldcraft) uses a file format called "RMF" to save your work (or .map for others). This file format contains brush/vertex information, texture information, entities, visgroups, groups, whatever. It differs from ".map" in the way that ".map" has the bare minimum information needed to compile; it does not store the Visgroup Data or any other information used solely by Worldcraft/VHE.

With your map ready to compile, you start the compiling process. All compile tools are controlled via command-line parameters; something Post-DOS computer users may not be too accustomed to. Refer to other tutorials on how to do that.

There are several ways to compile:

- Batch File
Creates a ".bat" file, a list of commands to be executed so you don't have to retype them every time. Efficient, good.

- Batch File GUI
For the DOS-illiterate or the lazy (that's me!), there are plenty of Graphic User Interfaces that will generate .bat files for you. I personally recommend Nemesis's Batch Compiler here, as I've found it easy and simple to work with.

- Worldcraft/VHE Compile GUI
Do not use this, please. With bigger and more complex maps, it simply is not worth it to have the editor still open, eating up resources (more on this later). Also, it doesn't really compile things too well and doesn't offer as much control or flexibility as the other two methods.

CSG-----
Constructive Solid Geometry
Brushes and entities are organized in a "hierarchial" structure. Every brush and/or entity has a number, ordered by how they were created in the editor.

This tool basically takes all the brushes and creates the various hulls for HL to interpret. (If you can give details of these what each hull does PM Jake and he'll add it to the tutorial).

It also assigns texture information and calculates the number of planes in your map. Half-Life (or CSG actually) creates polygons from cutting out certain portions of a plane and rendering a texture on top of it, as defined by the vertex coordinates of a brush. This is why brushes that are not vertex-manipulated carefully are "invalid"; a polygon can not lie on two planes at once, only one. This is also why 2-point clipping never produces invalid solids. It always creates a face with ONE plane.

In addition at this stage of a compile, faces covered with "NULL", "SKIP", "CLIP", etc. are deleted from the map. Refer to ZHLT documentation for more information on what NULL does and its potential uses.

If you don't know what a plane is, I suggest you brush up on your Middle School geometry skills...

BSP-----
Binary Space Partitioning
With the planes defined, BSP sorts through the planes and determines which can even be rendered/visible at all. It seperates the portions that are visible into "leaves", or polygons. Leaves that are parallel and flush against another leaf are never rendered/calculated unless it is an entity. For example, if you left a crate on the floor a WORLD brush, the bottom would not be rendered as it is against the floor, but it would still cut the floor brush it is on into smaller pieces. Since it creates leaves, it also must apply texture data and what not.

Also, clipnodes are created, as the leaves are calculated. With bigger maps, many authors found themselves hitting the dreaded clipnode limit. Newer revisions of CSG attempt to solve this by the "-clipnodeeconomy" parameter. It does not create clip nodes for func_illusionaries, which are used heavily in mapping.

Your map is basically playable at this point... Unless you have a LEAK. I'm not going to go over leaks in this tutorial, as that is not it's purpose.

VIS-----
Visible Information Set
This tool takes all the leaves in your level and basically organizes them, finding out which leaves are visible from certain points. The way it does this is through PORTALS. It essentially groups leaves into, well, groups. Between these groups are portals. Certain portals can see certain groups of leaves. Take this example picture:

user posted image

The blue lines are PORTALS. The red areas are LEAVES.

Let's say you got 2 leaves (XX and YY), now VIS checks if any point (brush) in Leaf XX can see any point in Leaf YY by connecting and by checking the intersection points with the players sightline (viewing frustrum/cone).

If the sightline goes through the portal, then everything in Leaf XX is visible from Leaf YY (this is what the engine thinks anyway)

Otherwise nothing in Leaf XX is displayed as you can't see anything in Leaf XX from Leaf YY.

Various bits of information and the diagram from: HERE.

RAD-----
Radiosity Lighting (refers to the method that Half-Life uses to calculate light; more information here. I sort of summarize some information there, in here.

The article referred to above does a very good job of explaining how RAD calculates light. Basically, it uses information from VIS to get information about the leaves. From the leaves, it can calculate how light will bounce off and how shadows will form and such. Be aware that It simulates light by overlaying a monochrome bitmap over the affected leaf, simulating light.

The "-bounce" parameter in RAD controls how many times the light bounces off. It takes very little time to do this, and helps achieve some good contrast while lighting areas sufficently (1-4 bounces are recommended at most). Light bounces off surfaces, but some amount is absorbed. Eventually, the bounces will reflect very little light, making it pointless to set it to higher values. What happens is that RAD sorts through the map not really to directly calculate the light, but to create a data structure that can be easily understood and processed.

Also, RAD does not use individual polygons; it instead uses smaller areas called "patches" to refer to when overlaying the monochrome bitmaps on the map geometry. The "chop" parameter controls how big these patches are. Values below 64 don't work, as it will really take too much memory and computing power to do that. Values above 64 will take less time to compile, but lighting will look blocky and generally ugly. This is why diagonal shadows are blocky; lightmaps or patches are low resolution, and anything more detailed would take longer to compile than it already does.


Thanks for reading. user posted image

Rate This Article
This article has not yet been rated.

You have to register to rate this article.
User Comments

No User Comments

You must register to post a comment. If you have already registered, you must login.

Latest Articles
3rd person View in Multiplayer
Half-Life 2 | Coding | Client Side Tutorials
How to enable it in HL2DM

By: cct | Nov 13 2006

Making a Camera
Half-Life 2 | Level Design
This camera is good for when you join a map, it gives you a view of the map before you join a team

By: slackiller | Mar 05 2006

Making a camera , Part 2
Half-Life 2 | Level Design
these cameras are working monitors that turn on when a button is pushed.

By: slackiller | Mar 04 2006

Storing weapons on ladder
Half-Life 2 | Coding | Snippets
like Raven Sheild or BF2

By: British_Bomber | Dec 24 2005

Implementation of a string lookup table
Half-Life 2 | Coding | Snippets
A string lookup table is a set of functions that is used to convert strings to pre-defined values

By: deathz0rz | Nov 13 2005


Latest Comments
knock knock
General | News
By: MIFUNE | Dec 31 2017
 
knock knock
General | News
By: omega | Dec 22 2016
 
knock knock
General | News
By: MIFUNE | Oct 10 2015
 
New HL HUD Message System
Half-Life | Coding | Shared Tutorials
By: chbrules | Dec 31 2011
 
knock knock
General | News
By: Whistler | Nov 05 2011
 
Particle Engine tutorial part 4
Half-Life | Coding | Client Side Tutorials
By: darkPhoenix | Feb 18 2010
 
Particle Engine tutorial part 2
Half-Life | Coding | Client Side Tutorials
By: darkPhoenix | Feb 11 2010
 
Particle Engine tutorial part 3
Half-Life | Coding | Client Side Tutorials
By: darkPhoenix | Feb 11 2010
 
Game Movement Series #2: Analog Jumping and Floating
Half-Life 2 | Coding | Shared Tutorials
By: mars3554 | Oct 26 2009
 
Particle Engine tutorial part 5
Half-Life | Coding | Client Side Tutorials
By: Deadpool | Aug 02 2009
 

Site Info
297 Approved Articless
8 Pending Articles
3940 Registered Members
0 People Online (6 guests)
About - Credits - Contact Us

Wavelength version: 3.0.0.9
Valid XHTML 1.0! Valid CSS!