General Concepts 102: Lesson 2
Compiling

Before starting, I know many of you will be tempted to skip over the technical information presented here, but believe me, it's something you need to know to make a quality map.  If you don't completely understand it, don't worry.  It doesn't become truly important until you get to the point where you need to add Hint Brushes.  And you won't need these until your maps get noticeably more complicated.  So push forward, my young Padawan!

Up until this point, to compile, you've only been using "bsp FullVis." in the BSP Menu.  So what are all those other options for?

To understand the different options, you need a basic comprehension of what exactly goes on when you compile your MAP  All the MAP file itself consists of are brush references (basically a very large wireframe version of your map plus the textures on them), patch information (we will get to this in a few lessons), and entity locations - all in a large plain text file.  It would be very inefficient for the JK2 engine to read the MAP line by line trying to place lighting where it should be, entities where they should be, etc, etc, so we go around this limitation by making the MAP easy for the game engine to read beforehand - this is the process called compiling.  To view the MAP by code, simply load it in a basic word processor, such as Notepad.

Compiling a map occurs in up to three stages.  The first stage is the BSP process, or Binary Space Partitioning.  This process takes your MAP file and first creates a BSP file.  All the space inside the walls of your map are divided into convex shapes that are called Leaf Nodes.  All the major sections of the Leaf Nodes (that aren't separated by solid brushes) are turned into Portals.  The portal information is recorded into a PRT file.  A portal is basically each and every largest possible completely open area existing in your map with a convex shape (a small empty box of a room only has 1 portal - the entire room.  Two empty square rooms connected by a straight hallway will have three portals - each room and the hallway.).

Thus, the BSP process converts your map.MAP into a map.BSP and a map.PRT.  The BSP process is technically the only absolutely necessary part of the compile process.  If you halt the compile at this point, you will have a playable map - however, lighting information has not been calculated.  Also, the engine has not yet been told which parts of your map are visible from the other parts of your map.  That is the next stage of the process.

The second compile stage is the VIS process, or Visibility.  This process takes your BSP and PRT files to calculate visibility information.  It reads the PRT (Portal) file and determines which portals are visible from which other portals.  It creates a large table called a PVS Table, or Potential Visible Set.  This table is then written into the BSP and the PRT file is deleted.

Thus, the VIS process converts your map.BSP and map.PRT into a map.BSP.  The VIS process is vital because without it, the JK2 engine would draw every other part of your map at every moment in time.  This is utter hell for framerate and r_speeds (we'll get to that in the next lesson), so this is an important step.  It can, however, sometimes be skipped over if all you want to do is take a glance at your level's architecture and don't want to take the time to go through the entire VIS process (which can be hours and hours long with a more complicated MAP).  This stage is the one that determines if you map has any leaks.

The third and final compile stage is the LIGHT process, formerly known as the RAD process in Q3A.  The LIGHT process divides the textures in your map into small pieces which it uses to calculating appropriate lighting information, based on the placement of your light entities and light-emitting shaders (will get to this later, too).  It also calculates partial light reflection information for added realism and looks at possible brushes that would block light and cast shadows.  Thus, the original color and brightness level of the textures in your map are altered and a lightmap is generated, which is then added to the BSP file.

Thus, the LIGHT process takes your existing map.BSP, adds lighting information to it, and rewrites it.  While this stage is not necessary to the compile process, nor does it affect framerates, it is absolutely necessary to create a good looking level.

That's all you really need to know about compiling.  So, armed with this information, what does that mean for the items in our BSP Menu?  Well, here's the rundown, in the order I think you should need to know them.

  • bsp FullVis - This process performs all three sections of the compile process, BSP, VIS, and LIGHT.  When you want to see basically how your final release will look, this is the compile to do.

  • bsp FullVis (1/2 LMs) - This process is the same as bsp FullVis, except that in the LIGHT process, only 1/2 the regular number of passes is calculated - meaning your lightmaps (LMs) are half as complex.  This means the final lights in your BSP will appear more blocky than they would in your final. 

  • bsp FullVis (Extra) - This process is the same as bsp FullVis, except that in the LIGHT process, twice as many passes are calculated, meaning your LMs will be twice as complex.  This means that the final lights in your BSP will appear as smooth as they possibly can.  You only need to do a bsp FullVis (Extra) for the absolute final compile of your map.

  • bsp FullVis (NoLight) - This process performs only the first two sections of the compile process in their entirety, BSP and VIS.  There will be full (100%) lighting on all surfaces.

  • bsp FastVis (NoLight) - This process performs only the first two sections of the compile process, BSP and VIS.  The VIS process, however, will skip the last few passes in determining visibility.  This means that your map's  portals may be able to see more other portals than they normally would in bsp FullVis.  This can cause a slight decrease in framerate, although it is usually not too severe.

  • bsp FastVis (1/2) - This process is the same as bsp FastVis (NoLight) except that the lighting is calculated at the same complexity level as bsp FullVis (1/2 LMs).

  • bsp NoVis (NoLight) - This process performs only the BSP process.  No visibility and no lighting information will be calculated.  This is useful only because it is the fastest of the compile processes, and still calculates full architectural information.

  • bsp Relight - This process performs only the LIGHT process and is only to be used after a bsp FullVis.  This process will rewrite the lighting information of your map, and is thus useful if you change the brightness levels of some of your light entities and nothing else.

  • bsp Relight (1/2 LM) - This process is the same as bsp Relight except that the lighting processes are at the complexity level of bsp FullVis (1/2 LMs).

Quite a lot of difference, eh?  The processes you will most likely use the most are bsp FullVis for near final compiles (or to see how your complete level will look at any point in time with accurate framerates), bsp FastVis (1/2) for you to look at your map while you're making it, and bsp NoVis (NoLight) to take a quick look at brush architecture in-game when you change something minor.  Always use bsp FullVis (Extra) for your final map compiles.

Try compiling your basic MAP in bsp NoVis (NoLight) and in bsp FullVis (Extra).  Notice the significant differences in compile times as well as the significant differences to your map in the game itself.

Back to Home