|
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.
|
|
|