This is an old revision of the document!


It's nice to know that putting some hint and area portals in your map and using detail brushes may somehow increase the performance, but if you wish to use them perfectly, you have to understand the VIS process.


By the end of this tutorial you will know how performance optimization works in the Quake 3 Engine and what you have to do to profit from it.


You need to know the basics of mapping.

A note on footnotes

I often use footnotes1) - they provide additional information that isn't necessary for understanding the tutorial, so they can be skipped. Reading them may provide deeper insights, interesting trivia or corrections on inaccurate simplifications though.

About Portals

What are Portals?

When you do the -vis2) compile of your map, Q3Map2 splits the map into regions. You can think of them as rooms for now.3) Then it checks which room can be seen from which other room and saves that.

When you're in the game, it checks which room you4) are in and only renders the rooms that have been saved as visible. By not rendering the rest it saves time, which means you get more FPS. That's always good.5)

These regions don't necessarily coincide with the rooms though. A room can contain many regions. Very many. But it's in your interest to limit the number of regions. Why?

  • Q3Map2 can only handle so many regions. If you have too many regions, you'll get an error.
  • Since the visibility has to be calculated for each region, the -vis compilation duration increases with increasing number of rooms. And compiling takes long enough as it is, so it's in our interest to save time, right?
  • If you have too many regions, handling them in-game takes increasingly long, at the cost of performance.

So having one region per room is usually enough. How do you accomplish that? How are those regions determined anyway? Q3Map2 doesn't know rooms, after all, only brushes!6) And what are Portals?

The last question is easily answered: Portals are the boundaries between regions. For answers to the other questions: Read on!

How can I see where the portals are?

If you want to understand how portals are generated it helps a lot to know where they are. That's pretty simple: Supply the -saveprt setting to Q3Map2 when doing the -vis compile and a mapname.prt will be created, containing information on the portals. It can be viewed with the prt viewer plug-in in Radiant, available at TODO: Lookup prt viewer menu entry.

TODO: Insert image of prt viewer in radiant

How are portals created?

Every brush creates portals at its faces, splitting the region it is in into multiple sub-regions.

TODO: Insert image of portals in Torus-shaped room

Keeping portals from being created

When you create details using brushes, you don't usually want them to create new portals. When you have a table with a computer on top in your room, it's not necessary to have separate regions for below and above the table so the computer won't be rendered when you're below the table - both because the camera will hardly ever be below the table and because the possible decrease in rendering time is most likely not worth the increased number of computations required by the additional regions.

So how do you keep the table (or any brush) from creating new portals? By marking it as detail. Select the brush, then right click and select make detail, or press Ctrl+M. TODO: Verify Ctrl+M is correct.

TODO: Insert image of RMB menu with “make detail” highlighted

You can hide all detail brushes by pressing Ctrl+D or from the TODO: menu name? menu. This is useful for checking whether you forgot any, or whether you introduced leaks.

Yes, that's right: Your map will leak if it's only separated from the void7) using detail brushes, which should make sense to you if you think about it.

So in general you'll want to mark all the detail as detail and only keep the basic structure of the room, as is implied by the name of none-detail-brushes: structural.

Manually creating portals

So you know how portals are automatically created and you how how to prevent that, but how do you manually create them? Automatically created portals face the same direction as the brush faces that created them, but what if you want angled portals in the corners of a corridor?

TODO: insert image of said example

The answer: You can give Q3Map2 hints on where to create portals using the textures/system/hint texture. But be careful: Any brush side with that texture on it will (potentially) create a new portal, so creating a thin brush with hint on both sides may create more portals than you wanted.

So only use the hint texture on one side of the brush and put textures/system/skip on the others to tell Q3Map2 to skip them.

TODO: insert image of hint brush with skip on sides here in previous example here, as well as a prt viewer version of it


1) like this one
2) short for visibility
3) They're not actually necessarily rooms, but let's stick with the simplification for a moment, it helps understanding them.
4) i.e. the camera
5) Actually, not necessarily - physics calculation may turn out differently when done with greater precision (i.e. more FPS) - that's why the FPS of the physics simulation of Doom 3 are fixed at 60: Player with high FPS could jump higher otherwise. But as far as we're concerned, more is better.
6) Patches are ignored in the VIS stage. They're calculated in-game with varying fidelity based on how far away they are. The -patchmeta switch for the -meta stage forces them into the .bsp though - that's especially important when converting a map to an .ase model because they'd otherwise be ignored. But even then they're ignored in -vis.
7) the big nothing outside the map
tutorials/visibility/hintportals.1335272464.txt.gz · Last modified: 2012/04/24 15:01 by mrwonko
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki