docs/manual/Q3Rad_Manual/ch11/pg11_1.htm

   1 <html>\r
   2 <head>\r
   3 <title>Q3Radiant Editor Manual: Page 11.1</title>\r
   4 <link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">\r
   5 </head>\r
   6 <body>\r
   7 <h1 class = "MsoTitle">Q3Radiant Editor Manual</h1>\r
   8 <hr>\r
   9 <h1><a name = "tools8">Tools 8: Compiling Maps</a></h1>\r
  10 \r
  11 To turn a map file from editor code into game code, it must be\r
  12 processed or "compiled". In Quake engine gaming, this is often\r
  13 referred to by the name "BSP", as in "I need to BSP my map before\r
  14 you can play it." The word "BSP" is actually an abbreviation\r
  15 for "binary space partition", the type of data organization\r
  16 procedure John Carmack used when creating the graphic engine for\r
  17 "DOOM".\r
  18 \r
  19 <p>The primary BSP process builds the game spaces,\r
  20 establishes the position of entities, and builds a lighting map of\r
  21 the arena. Altogether, there are four distinct processes that\r
  22 can be run together or separately. The first, the bsp process\r
  23 establishes the data organization of the map. The second phase, the\r
  24 vis process, builds the walls and internal spaces. The third\r
  25 process lights the map, calculating brightness and shadow and the\r
  26 color of the light that falls on every map surface. The fourth and\r
  27 final process is the Bot bsp, which creates the area (.aas) file\r
  28 that the bots use to navigate the map.\r
  29 \r
  30 <p>The size and complexity of a map and the computer's raw\r
  31 processing speed determine how long it will take a map to compile.\r
  32 Tiny one-room maps that lack detail or numerous lights will compile\r
  33 rapidly.  As maps become larger, are broken up into more\r
  34 spaces and have more complex lighting, the speed of compile\r
  35 drops.\r
  36 \r
  37 <p>Generally speaking, if you have an older, slower processor, you\r
  38 may want to make very small maps.\r
  39 \r
  40 <p><div class = "subheading">The BSP Menu</div>\r
  41 \r
  42 The bsp menu contains a number of compile options. The process\r
  43 you choose will depend on what you are doing with the map at the\r
  44 time you choose to compile.\r
  45 \r
  46 <p><b>novis</b> - Only the bsp function is performed. Checks\r
  47 for map leaks. No light information is created, so the map is seen\r
  48 at "fullbright". Because there are no shadows to get in the\r
  49 way, this mode is also good for looking for overlapping brushes,\r
  50 and texture misalignment.\r
  51 \r
  52 \r
  53 \r
  54 <br><b>fastvis</b> - Performs a bsp and a quick version of the vis\r
  55 process. The entire world is made into a single bsp partition. It's\r
  56 fast, but when you look in a particular direction, you see every\r
  57 single detail in that direction. Nothing is blocked. A light map is\r
  58 created. This mode was used for space maps.\r
  59 \r
  60 \r
  61 \r
  62 <br><b>fullvis</b> - the world is subdivided and broken up\r
  63 into smaller chunks so you can see only what is logically in your\r
  64 view. A light map is created. This is what is used to check\r
  65 polygon-in-view counts. Combined with light extra, it is the final\r
  66 compile for all maps.\r
  67 \r
  68 \r
  69 \r
  70 <br><b>entities only</b> - When you add or subtract non-brush model\r
  71 entities from a map, use this compiler. It's very quick. If you\r
  72 change the brush components of a brush model entity (like a trigger\r
  73 or a door), you must do a compile that includes a vis stage (fast\r
  74 or full). If you are only changing the properties, an entities-only\r
  75 will do. However,, if a brush model entity also has a md3 model\r
  76 component, the map must be at least fastvis'd for that entity to\r
  77 appear in the map.\r
  78 \r
  79 \r
  80 \r
  81 <br><b>relight</b> - Use only if no geometry (or light emitting\r
  82 textures) have been changed. It will rebuild the light map with the\r
  83 new information.\r
  84 \r
  85 \r
  86 \r
  87 <br><b>(nocurves)</b> - This function is always a modifier to\r
  88 another bsp command. It does (or doesn't do) what it says. The map\r
  89 is compiled without curves.\r
  90 \r
  91 \r
  92 \r
  93 <br><b>(nowater)</b> - This function is always a modifier to another\r
  94 bsp command. The map is compiled without water, lava, or slime.\r
  95 \r
  96 \r
  97 \r
  98 <br><b>(no light)</b> - This function is always a modifier to\r
  99 another bsp command. No light map is generated. A fast way to check\r
 100 polycounts. Most often used in conjunction with the novis bsp\r
 101 command.\r
 102 \r
 103 \r
 104 \r
 105 <br><b>(-light extra)</b> - This function is always a modifier to\r
 106 another bsp command. A finer degree of subdivision is used to\r
 107 create a more detailed light map. This is generally only done when\r
 108 the lighting is going through a final fine-tuning because it takes\r
 109 a long time. Instead of being calculated in 16 unit increments, the\r
 110 light is calculated in 8 unit increments. This has no effect on\r
 111 final map size, only on the time needed to compile.\r
 112 \r
 113 <p align = "center"><a href = "../ch10/pg10_1.htm">Back</a> | <a href = "../index.htm">Home</a> | <a href = "../ch12/pg12_1.htm">Next</a>\r
 114 \r
 115 </body>\r
 116 </html>