https://wiki.unvanquished.net/api.php?action=feedcontributions&user=Seana11&feedformat=atomUnvanquished - User contributions [en-gb]2024-03-29T08:39:16ZUser contributionsMediaWiki 1.25.3https://wiki.unvanquished.net/index.php?title=Old/Mapping&diff=1111Old/Mapping2012-12-03T20:14:12Z<p>Seana11: /* Size Guidelines */ Changed meters to qu</p>
<hr />
<div>==Overview==<br />
<br />
Map geometry is created using either a conventional modeling program (such as Blender) or with some variant of Radiant. Do note that if you intend on using Blender, you will need to use Radiant to perform a few final steps. This is discussed further below.<br />
<br />
Radiant is the name used to refer to id Software's map editing tools from Quake 3 onwards.<br />
<br />
* QuakeEd &mdash; Developed internally at id and used to create maps for Quake. Written for NextStep.<br />
* QE4 &mdash; Developed internally at id and used to create maps for Quake II.<br />
* QERadiant &mdash; A fork of the released QE4 source code by Robert Duffy.<br />
* Q3Radiant' &mdash; id Software's fork of QERadiant used to create maps for Quake III. Windows-only.<br />
* [http://icculus.org/gtkradiant/ GtkRadiant] &mdash; A port of Q3Radiant using the Gtk+ GUI toolkit, making it cross-platform (available to Linux and Mac OS X). Development stalled after 1.5 for a number of years, but has resumed with the recent release of version 1.6, which (for now) removes support for a number of games, including Tremulous.<br />
* [http://dev.alientrap.org/projects/show/netradiant NetRadiant] &mdash; A fork of GtkRadiant (?) by Alientrap, developers of the former (FOSS) Nexuiz project. The project page for this fork is currently down, but builds are still available from noted Tremulous mapper [http://ingar.satgnu.net/gtkradiant/ Ingar's site]. The Xonotic project is currently maintaining NetRadiant; source code is available from [git://git.xonotic.org/xonotic/xonotic.git their site] and is also [http://git.xonotic.org/?p=xonotic/netradiant.git viewable].<br />
* [http://darkradiant.sourceforge.net/ DarkRadiant] &mdash; A fork of GtkRadiant with the aim to improve the user interface and primarily intended to support Doom 3.<br />
* [http://www.redsaurus.net/00/node/4 MacRadiant] &mdash; A port of GtkRadiant to Mac OS X.<br />
<!-- TODO: provide a suggestion as to which to use --><br />
<br />
===Map editor comparison matrix===<br />
<br />
This table provides a comparison of all modern map editing tools available.<br />
<br />
{| class="wikitable"<br />
|-<br />
! rowspan="2" | Program<br />
! colspan="3" | Supported OSes<br />
! rowspan="2" | Last stable release<br />
|-<br />
! Mac OS X<br />
! Windows<br />
! Linux<br />
|-<br />
! [http://dev.alientrap.org/projects/show/netradiant NetRadiant] ([http://ingar.satgnu.net/gtkradiant/ Ingar's builds])<br />
| style="background:#5CEFA1" | 10.5, 10.6<sup>3</sup><br />
| style="background:#5CEFA1" | Yes<br />
| style="background:#5CEFA1" | Yes<br />
| 2011/03/09<br />
|-<br />
! [http://icculus.org/gtkradiant/ GtkRadiant]<br />
| style="background:#EB6767" | No<br />
| style="background:#5CEFA1" | Yes<br />
| style="background:#5CEFA1" | Yes<br />
| 2012/05/22 (v1.6.2)<br />
|-<br />
! [http://darkradiant.sourceforge.net/ DarkRadiant]<br />
| style="background:#EB6767" | No<br />
| style="background:#5CEFA1" | Yes (32 and 64-bit)<br />
| style="background:#5CEFA1" | Yes<sup>1</sup><br />
| 2012/07/16 (v1.7.2)<br />
|-<br />
! [http://www.redsaurus.net/00/node/4 MacRadiant]<br />
| style="background:#5CEFA1" | Yes<sup>2</sup> (Intel &amp; PPC)<br />
| style="background:#EB6767" | No<br />
| style="background:#EB6767" | No<br />
| Unknown (v1.4 and v1.5)<br />
|-<br />
! [http://quark.sourceforge.net/ QuArK]<br />
| style="background:#EB6767" | No<br />
| style="background:#5CEFA1" | Yes<br />
| style="background:#EB6767" | No<br />
| 2011/04/01 (v6.3)<br />
|-<br />
|}<br />
<br />
# Binary packages are not yet available (but have been promised by the developer).<br />
# Problems have been reported with Snow Leopard and Leopard, though there are workarounds. See the download page for more information.<br />
# Binaries are for Intel systems only. Requires that X11 be installed. Users of 10.7 can get this from the [http://xquartz.macosforge.org/landing/ XQuartz project].<br />
<br />
===Compilation===<br />
<br />
Creation of a map using either method is only part of the process; before a map can be played in-game, the map must then be <dfn>compiled</dfn>. This is a time-consuming process that can take hours even with new hardware. Compilation consists of several phases, discussed below. Note that it is not essential to understand precisely what happens in each of these phases. At a minimum, understand that compilation must occur before a map is ready to be played and that it is a highly time-consuming (though completely automated) process. Also understand that this process transforms maps that are editable by the the map editor (<code>.map</code> files) into files readable by the game engine (<code>.bsp</code> files).<br />
<br />
* '''Space partitioning'''. Map geometry is subdivided (partitioned) in half successively, effectively breaking the map down into progressively smaller chunks. The reason for this is to improve in-game render speed; this is done in such a manner that the engine can quickly determine what portions of the map the player is not facing, and therefore avoid having to render such areas. <!-- TODO: create a .gif showing what this might look like --> <!-- TODO: create some kind of "tech note" template with verbiage indicating that artists may safely ignore this bit --> The scheme <!-- scheme isn't really a good word, because BSP alone does not describe the algorithm for selecting good splitter planes --> by which this is done is referred to as [http://en.wikipedia.org/wiki/Binary_space_partitioning binary spatial partitioning], and this (as well as the data structure storing this information) is most often referred to as BSP. With each split, the compiler attempts to minimize the amount of geometry that must be cut to minimize the resulting size of the BSP. <!-- TODO: elaborate --><br />
* '''[http://en.wikipedia.org/wiki/Potentially_visible_set Potentially visible set] calculation'''. This stage of compilation takes the rendering boost that BSP provides by <!-- TODO: fact check this; for all I know, view cells in Quake are not related to the BSP --> calculating which regions of the map are visible when viewed from other areas. Each of these areas for which a potentially visible set (PVS) is calculated is referred to as a <dfn>cell</dfn> or <dfn>portal</dfn>. <!-- not sure which of "cell" or "portal" is preferred parlance in Quake-speak --> As an example, imagine standing in a room in a house. <!-- TODO: a pic would be nice --> Using only BSP, the game engine could very quickly determine which rooms you are not facing (as if the rooms were made of glass and every room were visible from every other room), and skip drawing them. However, while standing in that room, there are many other rooms in the house that you likely also cannot see (as the walls of the rooms are probably not glass and very much opaque). This is PVS in a nutshell: for that room, the PVS might only be an adjoining hallway and a closet (assuming that the doors are open). In a large house with many rooms, in a worst-case scenario (where both the player is facing the hallway and the closet at the same time), the engine still has very little to draw as compared to the entire house. This is discussed in greater detail on [http://fabiensanglard.net/doom3/dmap.php Fabien Sanglard's blog].<br />
* '''Lightmap calculation'''. Using the position, color, and type <!-- there are different types of lights in Q3, right? --> of lights placed in the map editor, the compiler generates a static <dfn>lightmap</dfn> which is essentially painted over (blended with) the map textures at run-time to create shadows and areas of light and dark. (Otherwise, the map would be the same brightness throughout and devoid of shadow). Note that this is not the extent of the engine's lighting capabilities; additional (dynamic) lighting is performed in real-time to create effects such as light generated from muzzle flashes. <!-- TODO: elaborate further --><br />
<!-- ^^^ we keep referring to "the compiler", when really it's separate programs. I am not sure what the name of these are --><br />
<!-- TODO:<br />
===Conventional modeling vs. Radiant===<br />
<br />
discuss the difference between creating brushes out of triangles with Blender (or just triangles, idr what that is called) and actually creating brushes with constructive solid geometry)<br />
--><br />
<br />
===Using other than Radiant to create maps===<br />
<br />
Conventional modeling software other than Blender is outside of the scope of this document; only Blender will be discussed. <!-- though any enterprising wiki editors are free to change this --><br />
<br />
While geometry other than triangles may be used during map creation, the map compilation tools can only handle brush geometry; as of now, the <code>.map</code> exporter for Blender can only convert polygonal geometry (triangles) to brushes, and as such it would be pointless to use anything else during the construction of a map except as a placeholder. <!-- not sure of this: Also note that as of now, entity and light placement must be done in Radiant --><br />
<br />
A comprehensive guide of using Blender to create map geometry ready for Radiant and the compilation tools is available from [http://www.katsbits.com/tutorials/blender/map-basics-tutorial.php katsbits].<br />
<br />
==Acquiring the game pack==<br />
<br />
To use any version of Radiant to create maps for Unvanquished, you will need to download the [http://ingar.satgnu.net/gtkradiant/files/gamepacks/UnvanquishedPack.zip associated game pack].<br />
<br />
The contents of the game pack are as follows:<br />
<br />
* <code>games/</code><br />
** <code>unvanquished.game</code><br />
* <code>unvanquished.game/</code><br />
** main/<br />
*** entities.def<br />
*** default_shaderlist.txt<br />
** game.xlink<br />
** default_build_menu.xml<br />
<br />
==Installing the game pack==<br />
<br />
===Mac OS X===<br />
<br />
====NetRadiant====<br />
<br />
Installation of the game pack on Mac OS X is slightly more complex, as you must place the game pack within the application's package:<br />
<br />
# Extract <code>UnvanquishedPack.zip</code> if you have not already done so. On some versions of Mac OS X, Safari is set by default to do this.<br />
# Navigate to your copy of Radiant and right-click it.<br />
# Select "Show Package Contents".<br />
# Navigate to <code>Contents/MacOS/install</code>.<br />
# Manually copy the <code>unvanquished.game</code> file (not directory) from the <code>game/</code> directory of the unzipped archive to the <code>Contents/MacOS/install/game/</code> directory of the application package.<br />
# Manually copy the <code>unvanquished.game</code> directory (not file) from the unzipped archive to the <code>Contents/MacOS/install/</code> directory of the application package.<br />
<br />
Note that you cannot copy all the files at once because Mac OS X lacks a "merge" feature; if you attempt to copy both folders at once, you will be prompted if you would like to overwrite the existing "games" folder with the new one. If this happens, cancel the operation.<br />
<br />
The directory tree should look as follows:<br />
* Contents/<br />
** MacOS/<br />
*** games/<br />
**** darkplaces.game<br />
**** nexuiz.game<br />
**** ...<br />
**** ufoai.game<br />
**** <span style="color:#49ab47;">unvanquished.game</span><br />
**** warsow.game<br />
**** xonotic.game<br />
*** <span style="color:#49ab47;">unvanquished.game/</span><br />
**** <span style="color:#49ab47;">default_build_menu.xml</span><br />
**** <span style="color:#49ab47;">game.xlink</span><br />
**** <span style="color:#49ab47;">main/</span><br />
***** <span style="color:#49ab47;">default_shaderlist.txt</span><br />
***** <span style="color:#49ab47;">entities.def</span><br />
Note that most of the contents of the tree have been omitted for brevity. Files that were added are highlighted green.<br />
<br />
===Linux===<br />
<br />
====GtkRadiant 1.6====<br />
<br />
GtkRadiant 1.6 can read game packs from the <code>~/.radiant/1.6.2</code> directory. Place the contents of the extracted archive there.<br />
<br />
====NetRadiant====<br />
<br />
For the game pack to work with NetRadiant, the contents of the game pack must be placed in NetRadiant's installation folder.<br />
<br />
==Design mentality==<br />
<br />
This section is oriented towards those with less experience mapping.<br />
<br />
There are many potential pitfalls of map creation. Possibly the easiest to fall into is spending too little time on design and spending too much time on map details before even having a working base design. There is an adage that applies well here: "Weeks of effort will save hours of planning." Before you begin creating, do not concern yourself so much with visual elements but the physical layout of the map.<br />
<br />
A good strategy is to use placeholder textures (such as those containing only text labels to identify what each finished surface should be, such as "cement wall" or "window") and very basic geometry at first, then playtest with as many people as possible as much as possible to evaluate gameplay, making adjustments to the basic level geometry as necessary; the emphasis during this phase of development is making many small iterations to get feedback as fast as possible. Only when gameplay seems stable would you then begin adding details.<br />
<br />
When designing a map, consider the following:<br />
* What can players use to help themselves navigate the map? What would make a good landmark or how can different areas of the map be differentiated visually?<br />
* Is the map partitioned well visibly? Are there any areas that may cause poor performance?<br />
* Are corridors large enough to facilitate combat?<br />
* Does the map provide other good locations to build in aside the defaults?<br />
* Is the map biased towards one side or another?<br />
<br />
==Using Radiant==<br />
<br />
Shortcuts for different versions of Radiant are the same unless otherwise noted.<br />
<br />
===Selecting brush geometry===<br />
<br />
* Press and hold <span class="hotkey">Shift</span> and click objects to select them (or deselect them if they are already selected).<br />
* With nothing selected, press and hold <span class="hotkey">Shift</span> and click and drag to select multiple objects at once in a rectangle.<br />
<br />
===Editing brush geometry===<br />
<br />
* Click and drag to create a new brush.<br />
* With a brush selected, click and drag the mouse cursor to change the size of the selected brushes.<br />
* Press <span class="hotkey">Esc</span> to deslect everything.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description<br />
! Key<br />
|-<br />
| Nudge Left<br />
| Alt+Left<br />
|-<br />
| Nudge Right<br />
| Alt+Right<br />
|-<br />
| Nudge Up<br />
| Alt+Up<br />
|-<br />
| Nudge Down<br />
| Alt+Down<br />
|-<br />
| Edit edges<br />
| E<br />
|-<br />
| Edit vertices<br />
| V<br />
|-<br />
| Edit faces<br />
| F<br />
|-<br />
|}<br />
<br />
===Placing entities===<br />
<br />
* Right-click in a 2d viewport to access the entity placement context menu. <!-- TODO: discuss which entities are required to place --><br />
<br />
===Navigating the views===<br />
<br />
====Changing viewport layout====<br />
<br />
To change the layout of the viewports:<br />
# Go to Edit &rarr; Preferences&hellip; or press <span class="hotkey">P</span>.<br />
# In the preferences dialog, select "Layout" (under "Interface") from the left panel.<br />
# Select your desired view layout.<br />
<br />
Note that to see this change in effect requires restarting Radiant.<br />
<br />
====3d viewport====<br />
<br />
* Scroll using the mouse wheel to dolly the camera forward or back.<br />
* Right-click on the viewport to look around. Using the mouse wheel to dolly the camera works while in this mode.<br />
<br />
====2d viewports====<br />
<br />
* Right-click and drag to move the views around.<br />
* Press <span class="hotkey">Ins</span> to zoom out and <span class="hotkey">Del</span> to zoom in.<br />
* Change the view with the toolbar button:<br />
<br />
[[Image:gtkradiant_toolbar_change_views.png|center]]<br />
<br />
==Size Guidelines==<br />
<br />
Player sizes, in quake units (qu)<br />
{|class="wikitable"<br />
|Dretch ||30<sup>3</sup><br />
|-<br />
|Granger ||40<sup>3</sup><br />
|-<br />
|Adv Granger ||40<sup>3</sup><br />
|-<br />
|Basilisk ||36<sup>3</sup><br />
|-<br />
|Adv Basilisk ||42<sup>3</sup><br />
|-<br />
|Marauder ||46×46×36<br />
|-<br />
|Adv Marauder ||50×50×40<br />
|-<br />
|Dragoon ||52×52×55<br />
|-<br />
|Adv Dragoon ||58×58×66<br />
|-<br />
|Tyrant ||64×64×92<br />
|-<br />
|Human ||30×30×56<br />
|-<br />
|Crouching ||30×30×40<br />
|-<br />
|Battlesuit ||30×30×72<br />
|}<br />
<br />
Players will need an opening at least 1qu wider to fit through (possibly 2). In addition, player bounding boxes do not rotate, which means diagonal corridors would need to be wider (thus the majority should be axis aligned<br />
<br />
Map scale:<br />
32qu = 1m<br />
<br />
Doorways should be a minimum of 128qu*128qu. Corridors should be a minimum of 196qu wide, although it is ''possible'' to use a mix of 196qu and 128qu (see Niveus for an example), and at most 512qu wide. Do not create corridors more than 1280qu long without plenty of cover.<br />
Currently large open areas and underwater areas are very human biased.<br />
<br />
Alien bases need cover to hide things behind, the entrances should be 128qu*128qu and should not be easily visible from outside other entrances.<br />
<br />
==New Features==<br />
<br />
You may be interested in the list of [[Engine features|engine features]].<br />
<br />
* [[Navigation Meshes]]<br />
* Additional shader functions (e.g., normal mapping) have been added; please see the [http://tremap.xtr3m.net/__Games/Xreal/Manual_Shader_1/ShaderManual.htm XReal shader manual] for more information.<br />
<br />
==Testing maps in-game==<br />
<br />
For testing purposes, it is most convenient to place your compiled <code>.bsp</code> file in the <code>main/maps/</code> subdirectory of the [[Running_the_game#Data_locations|data location]] appropriate to your system. Once you have done that, you can load your map with either the <code>devmap</code> or <code>map</code> commands after setting <code>sv_pure</code> to 0. The former allows using developer mode commands ("cheats") that make it easier to test. Additional commands are discussed on the [[testing]] page.<br />
<br />
==Testing maps publicly==<br />
<br />
You may opt to use a [http://188.40.187.142/ Map Test Server] to publicly test maps under development. You can upload a map there as soon as you've [[Packaging game data|packaged]] it accordingly.<br />
<br />
==Packaging maps for distribution==<br />
<br />
If you want to distribute your map to the world (either for testing or as a final release), you'll have to create a [[Packaging game data|package]]. Such packages may be distributed automatically via the server download feature or other means.<br />
<br />
==Resources==<br />
<br />
* [http://ingar.satgnu.net/gtkradiant/ Ingar's NetRadiant builds]<br />
** [http://ingar.satgnu.net/gtkradiant/files/gamepacks/UnvanquishedPack.zip Unvanquished game pack]<br />
* [http://www.custommapmakers.org/wiki/index.php/Main_Page Custom Map Maker's Wiki]<br />
* [http://dev.xonotic.org/projects/xonotic/wiki/Mapping Xonotic mapping resources]<br />
* [http://tremulous.net/forum/index.php?topic=14411.0 Useful mapping links thread on Tremulous forums]<br />
* [http://tremmapping.pbworks.com/w/page/22453205/Understanding%20Vis%20and%20Hint%20Brushes Understanding Vis and Hint Brushes]<br />
* [http://q3map2.everyonelookbusy.net/shader_manual/ Quake 3 Shader Manual] (outdated; please see the XReal shader manual)<br />
* [http://tremap.xtr3m.net/__Games/Xreal/Manual_Shader_1/ShaderManual.htm XReal Shader Manual]<br />
* [http://q3map2.robotrenegade.com/ Q3Map2 homepage]<br />
* [http://en.wikibooks.org/wiki/Q3Map2 Q3Map2 Documentation]<br />
* [http://shaderlab.com/q3map2/manual/ Additional Q3Map2 Documentation]<br />
<br />
===Tutorials===<br />
* [http://www.youtube.com/playlist?list=PL0DDC60C4E3A6CC64 Netradiant mapping video tutorial series] &mdash; Aimed at maping for AlienArena, but much of the information is the same.<br />
* [http://tremmapping.pbworks.com/w/page/22453200/Starting%20Tremulous%20Mapping Starting Tremulous Mapping]</div>Seana11