Building with Speed in Mind

How QBSP and VIS work:
This is stuff you don't really need to know about when you are getting started, however knowing how these programs work will improve your levels as you start to make better and more complex levels.
These are two of the the three programs that compile your map into a playable Quake level, "light" being the third. QBSP does the bulk of the actual level work, a large enough map can require up to 130 megs of combined physical and virtual memory to compile in QBSP.
VIS is what will make a properly made large map run smoothly. VIS takes the portals data generated by QBSP and essentially looks at all of your level from every possible angle and decides which areas can see each other. It then puts this information into the .bsp file. Without information the Quake engine will try to draw the entire this level at once, because it doesn't know which area's see each VIS cannot be run on a level that has leaks.
other. Essentially, a level which has not been VIS'd will not play well. You will want to run VIS "FULL" (-extra in expert mode) before releasing your level to the public. Running VIS on a large level can take between 30 minutes and 5 days! The more complex your level, and full of small parts within your rooms, the longer VIS will take.
VIS however can not make up for maps which have layouts which exceed the limits of the Quake engine. See the section below on "r_speeds"
   

Hunting the elusive leaks, using "pointfile"

! Keeping "snap to grid" on while you do most of your editing will save you a lot of leak hunting headaches.

 

 Finding Leaks:
Leaks are always very frustrating, but finding them quickly is part of what defines a good level designer. With a little patience and the right information you'll have them licked. When you have leaks, you have spots in your map that are open to the outside space. You must find the leaks or QBSP and VIS cannot fully process your level.

In Quake load the leaky level then type "pointfile" on the console, this will cause a string of dotted lights to be visible within your level, this trail should lead to your leak. Look all over your level, if you can't find the trail, you may have to "noclip" outside your level and look outside. You will likely get the message "not enough free particles" from Quake when you type "pointfile", don't worry for now. Try finding your leak first. If you can't find it, you will want to increase the number of particles, by adding "-particles 10000" to the command line parameters (you can try more, like 50000). This will increase the number of particles in the level that will lead to your leak. I always try it without the extra particles first, because then the particle string will not be as long and confusing a trail to follow. Once you find the leak, fix it in Worldcraft, and process it again. If there are more leaks, you will have to repeat these steps again.
   

! You won't get a fully accurate reading of your r_speeds until you have run a full VIS on your level.


Use "r_drawflat 1" to turn off the texturing in normal Quake, and see the polygon blocks that QBSP has broken your level up into.

 

 r_speeds
This is one of the most important, and limiting factors in current 3D level design. To make a good map you must keep the r_speeds within allowable limits. r_speeds dynamically measure various elements of a map. Try typing "r_speeds 1"in the console and then moving throughout your map (or any map). A series of numbers will begin to scroll up the screen . The third number is the one we are most concerned with, in the example picture it is "378". This number represents the number of polygons being drawn by the Quake engine in the current view. The present acceptable limit for this value is 500. If that number hits 799, Quake will not draw some areas, and walls will grey out, you may have seen this in maps which haven't been VIS'd yet. Also, levels with more than 500 visible polygons may not play well on slower systems, something every good level designer takes into consideration.

This means that you have to limit how big your rooms are, or how much detail they contain. To make things worse, rooms that VIS decides can be seen by each other will add to each other's count. Knowing how these work, how to block VIS, and planning your level before you start to build it can help keep the numbers down greatly.

The sky's the limit: Using a sky texture can also help bring down the polygon count because the sky uses very few polygons. QBSP doesn't break sky into many smaller polygons the way it does other surfaces. If not overused this is an effective method of reducing your r_speeds.

Dynamic lighting: As nice as those torches, flames and pulsing lights look, they are rendered in real-time and can take their toll on the playability of your level as a multiplayer level. Using them in low traffic, low polygon areas is ok, otherwise, try to keep them in single player levels.

The Forge's "tips and tricks" section has more info and links on r_speeds in "Fight the Lag".
Also check Somberfire's WCU class on making faster levels, 03/09/97.
   

Use "r_draworder 1" to see what parts of your map VIS can see too. This reverses the order thing are drawn, so the far things are drawn on top of the near things. Everything you see is being drawn by the game engine no matter which order they are drawn in. Wander around a few id levels to get an idea of how VIS sees things.

 

 Blocking VIS
The main trick to keeping the r_speeds down is knowing how to block VIS. After a while you should start to get a feel for how VIS works and what it can see. The main way to block VIS is essentially by using corners. There are two different styles of using corners to block VIS. The other way to block VIS is water, but in this age of transparent water, it has lost most of it's usefulness. See the next section "Transparent problem"

Corners: Whenever you see a hallway that connects two rooms, and the hallway goes around a corner, it's almost always done to block VIS . VIS is not absolutely precise either, just because you can't see the other room, it sometimes can, so you'll have to make up for that. If VIS were that precise, it would likely take over ten times longer to VIS your levels.

Big Wall: The big wall just causes you to go around instead of straight through, and manages to block VIS in the process providing the doorway is small enough. The best example of this is DM3 . The big wall there separates those two big rooms and blocks VIS. Without that wall, both of those rooms would be quite laggy.
  
Transparent problem: In the beginning, there was no transparent water, and level designers used water in levels as a way to block VIS, because areas in water couldn't see area's out of water and vice-versa. They would then be two separate VIS area's. If your map is VIS'd for transparent water, this will affect your r_speeds, no matter if you are using transparent water or not. You will have to decide for yourself if you are going to make your water transparent, but keep in mind that a lot of popular levels are converted to transparent water after they hit the net, and could then become a problem speed wise.
  
Multiplayer Friendly: When making good multiplayer levels, keep in mind that you as a level designer can influence how well your level will play, especially over modem connections.
Processor lag is caused by poor level design, high r_speeds, and use of too many different textures, or entities in a single area.
Net lag is caused by having too big an area where lots of action will take place in view of lots of other action. If that action exceeds the users bandwidth, chunks occur. (Don't confuse net lag with with latency lag [high ping], however excessive Net lag can increase your latency while in those big areas. It's bad enough fighting processor lag, throw in some net lag, and you've got a slideshow.)
  
Working Neat: Try to keep all your brushes evenly lined up, it will save you a lot of time searching for leaks and problems later on. "Snap to Grid" will help a lot.
   
[Previous] [Table of Contents] [Next]