|
|
| (15 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| | | {{LanguageBar|Map Compiling Theory}} |
| | {{cleanup:fr}} |
| | {{updatetranslation}} |
| == Introduction == | | == Introduction == |
| Many people simply do not know or understand how and why a Source map needs to be compiled. A few do not even realize that their maps ''are'' being compiled. In this article I am going to attempt to explain how the process of creating a playable map from an editor file takes place. Though I will go into some detail on certain aspects of the compile process keep in mind this is not a tutorial on how to compile a map. It is to help you to understand what has to happen and why other things (like preventing leaks) are important.
| | Tout comme la vidéo, les rendus, un programme, .... Votre maps à besoin d'être compilé. |
| | |
| The process of creating a playable Source map starts with an editor file. This file contains all the polygon data (aka brushes), entity data and texture data that will define how your finished map looks and acts. All the editors essentially serve the same purpose--to define how a level will appear. This is a key concept to understand: this is ALL the editors do. They do not create finished maps. All they do is give you a convenient way to prepare the polygon, lighting, and entity data for later processing.
| |
| Once you have built a level in your editor and saved it to disk for safekeeping you will want to playtest it in Source to see how it turned out. To make sure that all your entities are working properly, that your lighting is correct, and that you have no bad "brushwork". In Hammer many people just "Run" the map and then, after some time "thinking", their computer opens Half-Life 2 and plops them gracelessly into their map. This simplistic event hides a more complex set of operations taking place out of sight of the user.
| |
| Now, to the heart of the matter, what happens during that sometimes excruciatingly long "thinking time"? With even a decent sized map most people will notice their hard disk pounding away reading and writing data during this time. So what is your computer doing? It is compiling your map! Your editor has invoked a batch shell script (.bat) and is doing all of the following:
| |
| | |
| #Reading the .vmf file
| |
| #Executing the BSP program against the .vmf file
| |
| #Executing the VIS program against the new .bsp file
| |
| #Executing the RAD program against the .bsp file to add lighting information
| |
| #Moving your now finished .bsp to your Mods /maps directory
| |
| #Executing the game with parameters to run your map
| |
|
| |
|
| You may be thinking "Damn, that's a lot of stuff to do. What's it all for?". Well that's what I'm here to explain.
| | Sous Hammer vous indiquer ce que vous voulez, comme telles entitée, à telle emplacement, quelle éclairage vous voulez.... |
| | La compilation va rendre votre map jouable sous Source, et calculer ce que vous avez indiquer sous Hammer, comme la lumières qui nécessite de lourd calcule. |
| | Le compilateur part du VMF que vous avez éditer sous hammer, et le transforme en BSP. |
|
| |
|
| == Overview of the compile process ==
| |
| The following chart shows the overall process required to create a playable map file (.bsp).
| |
|
| |
|
| ''<placeholder>''
| | == Outils de compilations == |
| .vmf > VBSP > intermediate .bsp > VVIS > VRAD > final .bsp
| | La compilations sous Hammer passe par 3 outils: |
| ''</placeholder>''
| |
| | |
| == The compile tools == | |
| The table that follows should give you a good idea of what each tool does. The descriptions have been kept simple, since the tasks the tools perform involve some complex math and algorithms that you as a mapper have little need to know. As long as you understand what the tools are used for, that should suffice.
| |
|
| |
|
| <table> | | <table> |
| Line 31: |
Line 18: |
| </tr> | | </tr> |
| <tr> | | <tr> |
| <td class="type2"><b>[[Vbsp|VBSP]]</b></td> | | <td class="type2">'''{{L|Vbsp|VBSP}}'''</td> |
| <td class="type2">The BSP tool is the one that actually converts the .vmf file data into a usable .bsp file that the game engine can load. Once the BSP tool is run the map is essentially playable with the exception that it will have no visibility matrix and will have no lighting at all. Those crucial features are applied by the next two tools VIS and RAD.</td> | | <td class="type2">L'outils BSP à pour rôle de partitionner l'espace jouable, d'indiquer à Source tous les enplacements de ce qui sera nécessaire aux joueurs comme les entitées, les sons, les triggers,.... La lumière et les VIS sont calculé par les deux outils suivants. |
| | </td> |
| </tr> | | </tr> |
| <tr> | | <tr> |
|
| |
|
| <td class="type1"><b>[[Vvis|VVIS]]</b></td> | | <td class="type1">'''{{L|Vvis|VVIS}}'''</td> |
| <td class="type1">This tool creates the visibility matrix for the map based on the level's geometry. This matrix is what determines which polygons the player can see, might see, and can't see from any given point within the level in game. It is critical that this tool be run on every .bsp you create. If it is not run then the entire level will be visible all the time which would, in all but the simplest of box maps, make the map unplayable due to video-lag. In-depth information about VIS can be found at [[visibility determination]].</td> | | <td class="type1">Outils d'optimisation, à partir de la géométrie de votre map, il divise tous l'espace jouable en cube invisible pour le joueur : les VisLeafs, et determine lesquelle sont visible ou non. Cela évite de calculer en permanence tous l'enssemble du niveau. |
| | </td> |
| </tr> | | </tr> |
| <tr> | | <tr> |
|
| |
|
| <td class="type2"><b>[[Vrad|VRAD]]</b></td> | | <td class="type2">'''{{L|Vrad|VRAD}}'''</td> |
| <td class="type2">The RAD tool, or Radiosity tool, is responsible for generating and applying all lighting effects in a level. Everything from entity lights and the "sky" down to the lowly texture light has to be handled by this tool. A .bsp that has not had RAD run on it will appear pitch black in game or full-bright depending on video-mode and console-settings. This tool is normally the one responsible for slowing down compiles most of the time as it has to process huge amounts of data in the completion of its task. In-depth information about RAD can be found at [[RAD (technical)]].</td> | | <td class="type2">Calcul la lumière, dont la radiosité. En général l'outils le plus long lors de la compilations. |
| | </td> |
| </tr> | | </tr> |
| </table> | | </table> |
|
| |
|
| == Compile managers ==
| | {{ACategory|Level Design}} |
| * [[Batch Compiler]] - Supports Quake, Valve, Zoners, and CSTTools
| | {{ACategory|Theory}} |
| | |
| == Which compile tools? ==
| |
| Hammer ships with Valve's own compile tools. These are denoted by the presence of a 'v' preceding the tool name in the tools file name (i.e. [[Vbsp|vbsp.exe]], [[Vvis|vvis.exe]], [[Vrad|vrad.exe]]). In addition, Adam McKern is working on a new set of Source compiling tools ([[CSTBSP]], [[CSTVIS]], [[CSTRAD]]--known collectively as [http://www.ammahls.com/ CST]) that have refinements over and more options than the default tools. As of now CST does not have any big improvements over the Valve tools and it is not as thoroughly tested.
| |
| | |
| == See also ==
| |
| * [http://www.geocities.com/cofrdrbob/bspformat.html The Source Engine BSP File Format] - a look at the compile tools from a technical standpoint (from the author of VMEX and other Source tools).
| |
| | |
| [[Category:Level Design]]
| |
| [[Category:Theory]]
| |
This translated page needs to be updated.You can help by updating the translation.
Also, please make sure the article complies with the
alternate languages guide.(en)
Introduction
Tout comme la vidéo, les rendus, un programme, .... Votre maps à besoin d'être compilé.
Sous Hammer vous indiquer ce que vous voulez, comme telles entitée, à telle emplacement, quelle éclairage vous voulez....
La compilation va rendre votre map jouable sous Source, et calculer ce que vous avez indiquer sous Hammer, comme la lumières qui nécessite de lourd calcule.
Le compilateur part du VMF que vous avez éditer sous hammer, et le transforme en BSP.
Outils de compilations
La compilations sous Hammer passe par 3 outils:
| Tool |
Purpose |
| VBSP(en) |
L'outils BSP à pour rôle de partitionner l'espace jouable, d'indiquer à Source tous les enplacements de ce qui sera nécessaire aux joueurs comme les entitées, les sons, les triggers,.... La lumière et les VIS sont calculé par les deux outils suivants.
|
| VVIS(en) |
Outils d'optimisation, à partir de la géométrie de votre map, il divise tous l'espace jouable en cube invisible pour le joueur : les VisLeafs, et determine lesquelle sont visible ou non. Cela évite de calculer en permanence tous l'enssemble du niveau.
|
| VRAD(en) |
Calcul la lumière, dont la radiosité. En général l'outils le plus long lors de la compilations.
|
