EDIT: Just to make sure it is fully clarified, this tutorial covers things most of the others don't, and goes over some of the BSP editor's behaviors that may be odd.
Edited July 1st 2007 to make a bit more readable.This is something to read after you take a look at Jitspoe's basic mapping tutorials. If you are really intent on finding me, I'm usually on irc.gamesurge.net #gamesurge/#java as "ironfist" or a similar nickname.
-------------------------------------------------------------
BSP is an aging, yet still-capable map editor that was abruptly closed development-wise when the author found himself too busy a few years ago. Due to relative simplicity, and focus on Quake 2, it was chosen specifically to be configured for Digital Paint mapping, as DP is based on the Q2 engine. By following the included instructions and ensuring correct directory placement of BSP & DP, you can be up and ready to map in a few minutes. This article assumes you are now somewhat familiar with BSP, but includes a short introduction to various terms. If you need a dead-start tutorial check DP's forums/FAQ (wiki) to find one of Jitspoe's tutorials. Since DP is built on the Quake2 engine, more specific information (Q2 entities, brush flags, etc.) can be found on old Q2 mapping sites. One great resource is Rust, just plug in "Rust Quake 2 tutorial" in google!
To begin mapping, you need to first be aware of the following:
You need to come up with a plan for you map as a whole. This generally involves drawing the basic layout to get a good idea of how you want it to look. Also, specifically limit the design-time to what you've created. If you are like me, you will make two fatal mistakes. First, you will begin with no idea of how you want to map to look like. Secondly, the resulting "on-the-fly" creation will lead to a map with unfinished areas that require more filling in. Even then you are faced with the problem of not knowing when to stop - since you don't have a clear idea of how you want the map to be like, you continually add things until you "burn out," losing all interest in what you dumped a lot of creative effort in to. Remember: it's important to finish a map as soon as possible. HOWEVER, do not take this to mean you should sacrifice quality. What I mean is that you'll need your clear plan ahead of time so you can build the map with little difficulty, since you shouldn't be confronted with developmental "dead brain" situations, or simply losing interest.
Important mapping terms:
BSP/.BSP - You shouldn't confuse BSP the map editor and .BSP, the file format. A .BSP file (such as mymap.bsp) is generated by the compilers that will soon be mentioned. It contains all your lighting, entities, and brushes in a slightly compressed and binary-based manner.
.MAP - This is a file that can be edited in a text editor if you wish, but that would be quite hard. A .MAP file can be loaded in your map editor and modified as you wish, then you "compile" this map file into the final product for testing or distribution - the BSP file.
Polygon(s) - Since I will be talking about "polygons" a lot, you may want to be familiar with it. A polygon is simply a multi-sided figure! A polygon would obviously then consist of "faces." Take for example a box, with 6 faces (or sides). When we speak of how much processing power your map takes, we talk in terms of polygons being rendered. The more polygons (or specifically, faces) being rendered, the slower it is!
Brush - A multi-sided polygonal structure that is used to create your map. In most cases, it is simply "drawn" as a box into your map, allowing quick creation of walls, ceilings, floors, and outdoor areas. A brush can have one texture, or several different textures, one to each side. A common example is a rock structure with grass on the top of it. If you're curious as to how a brush is formed, it is done using intersecting planes (this is why some weird stuff happens as you drag vertices around by themselves to far extremes).
Brush Contents/Flags - Brushes can have several content types - or "flags" - these can be combined or used alone. These are used to create a "water" brush or a invisible barrier like the monsterclip/playerclip, and even allows you to emit light from different surfaces (faces) of the brush. See RUST tutorials for more information.
Entities - Entities could be considered a relative of the brush, but they serve an entirely different purpose. Rather than creating static scenery like a brush does, they set a location for special things to happen. This includes spawning ammo, paintball guns, or even creating a door from an existing brush.
VIS - qVIS, one of the three important compilers which assists in creating your map, makes judgements on how to divide up your map. What it divides is the areas you can see things from. Let's say you've got two rooms. A hall connects them, but it is formed like an L, so you can't see directly into the other room. VIS has already included information in your .BSP map file that says that the Q2 (DP) engine should not render room #1 when you are in room #2, because doing so is a waste of resources! One of the more tedious parts of mapping is getting qVIS to correctly divide a map up - it has a habit of dividing the map in ways a human would find lacking. To check how much of a map that DP is rendering in terms of the brushes (or specifically, polygons) at any one time, you can use the following...
R_SPEEDS 1 - Most often referred to as the "rspeeds" of a map, this command once entered in the DP console shows two statistics at the bottom-left of the screen. The first ("WPoly") is the number of polygons generated by all the brushes that are currently being shown in the direction you are looking. In any one place, this number shouldn't exceed 1000. While you can hit up at 1500, it's not a good practice. Sure, your monster gaming machine may laugh at 6000 rspeeds, but many people playing DP still use 8MB cards and 400MHz CPUs, not to mention Quake 2 eats up more CPU rendering polygons than the video card in most cases, so even these high numbers can slow your fast system as the Q2 engine struggles to send the commands to the video drivers. The second statistic is "EPoly." This is the number of polygons that are currently in view that are from the models in the game. A model is pretty much anything not related to your map structure that consists of brushes. This includes players, paintball guns, paintballs in the air, grenades, plants, etc. This number isn't near as deadly as "WPoly" since Q2 is more effecient at rendering these models. However, it isn't a good idea to copy and paste a gajillion plant entities to create a realistic weed farm and wonder why your map is slow!
qBSP - This is the first step of the compiling process, it searches out your map for "leaks." A leak is what occurs when a path taken from ANY entity in your map can reach the "outside" of the map at any time. You may have noticed the "hall of mirrors" effect when you look at areas of your first maps that don't have brushes, DP renders nothing there. This outside of the map leads to compartmentalization problems for the compiler, so it is important that you have no leaks, otherwise the important VIS process will be skipped. Luckily, when it fails, it generates a .PRT file that contains a line that goes from the entity to the outside of the map, so you can trace it and close the "hole." In BSP, to load this, simply go to File > Leak Check > Load (.pts), then select the PTS file in the same directory your .MAP file is in to load it. So what is the ill side effect of this? Since VIS is skipped, your ENTIRE map is rendered at a time, leading to severe speed issues. It is also not acceptable to enclose your map in a huge box, since it will still render everything due to that same little hole (although it will still perform VIS - but VIS is a little stupid and will do this to you!). Note that allowing the 3-step compilation process continue after a leak will result in your "r_speeds" going up very high -- make sure you have no leaks!
qRAD/ArghRad - The only difference between qRAD and ArghRad is that ArghRad is a modified qRAD by an outside person with special optimizations to help things look a bit more realistic. It is included with the DP BSP map editing ZIP package. This is the third and last step in the compiling process (VIS being the second), it calculates what are known as "light maps." Such light maps are "applied" to the various brushes in your map to give the effect of a lighted area. It should be mentioned that Quake 2's lighting and supported compiling is quite old, and the DP developer, Jitspoe, plans to move to a different form. RAD is both slow and not-that-impressive unless extra compiling options are enabled, but these options can take even longer to crunch numbers with.
Not scared away yet? Good! Now, I have decided to forgo regular BSP teaching stuff that you can find in Jitspoe's tutorials, or the ones on Rust. I'd like to cover some stuff I've done on my own that gave me horrid trouble, so you won't make the same mistakes!
Brush selectionAmazingly enough, BSP manages to make your journey through learning how to make a map a bit harder by making sure you learn this first little nugget: Since you primarily choose brushes to modify by clicking on the in the 3D view window, you may run into the problem of creating a FUNC_DOOR entity, then creating another brush right after that. You then find yourself perplexed; this new brush causes BSP to grey out everything else like it is still a FUNC_DOOR, and when you unselect it and select something else in the world, it shows it as a FUNC_DOOR. NOES! What happened? Well, you just need to remember that BSP "includes" the next brush you create after unselecting another brush with the brush you just unselected (see how clear that was?)! Select a door, unselect it, and create a new brush. Tada! it is part of that door. Now, select a regular brush instead and unselect, then create a new brush... you guessed it, it is a regular brush![/list]
