When you play, the game engine only render what the player can see.
Rules are simple but not intuitive to understand how it works.
When you compile your map, there is three step : bsp (the geometry), VIS (what i’m going to explain) and light (do you really need an explanation?). Everything happen in the second step.
The vis process will define what will be render by the game ( or what the player can see ). This is how we get great performances.
Summary
This tutorial is a lot longer than other. So it need a summary
- VIS explanation
- Loading portal file
- Second VIS exemple
- Structal VS Detail
- How to set a brush or a group of brushes to detail in Quark
- Adding hint to the second exemple
- Aera Portal
- The famous Leak error
VIS explanation
The VIS step divide the map into portals.
VIS will look at each portal individually and try to draw a line between any points from this portal to any other points of all others portals.
If a direct line can be drawn from a portal (p1) to any other portal (p2) then everything in p2 will be render/display as long as the player will be in p1.
That’s all.
Notes about definition & wording
- Sometimes peoples call these portals “clusters” or “blocks” or “aeras” or “vis nodes”, “leaf nodes” or something else… You have to take care of the context to understand correctly what they mean.
- Some others don’t think as portals or blocks, but as leaf that are between this portals/blocks/aeras.
In any case the concept remain the same. They all speak about the same things but not with the same words or metaphor.
Personally i always think with portal, not leaf. Keep that in mind. It’s easier to understand with that vision in mind.
VIS basic example
The first basic example is a simple corridor that turn at 90°.
In this situation, the game engine render everything.
But we can control this.
What we want to do is to avoid the rendering of the truck (the strange thing at the top right) because from this position, the player (at the bottom left in blue) have no chance to see that truck.
To do it, we have to create a new polygon with a specific shader (texture) on it. The shader must be “common/hint”. The texture of this shader is usualy green but it won’t be seen in game.
Therefor we will have three portals and they are all created by our hint brush during the second step at compile; the VIS step.
The following picture show you the result (the hint brush is in green ).
Think again to the definition: If a direct line can be drawn from a portal (p1) to any other portal (p2) then everything in p2 will be render/display as long as the player will be in p1.
In this cas, when the player is in the first portal ( P1, in orange ), he have no chance to see something in the third portal ( P3, in purple) because no direct line can be draw from P1 to P3.
Therefore, P3 isn’t displayed!
How to see the result?
Because we don’t have any line of sight from P1 to P3, you probably ask yourself how to be sur that P3 isn’t displayed when the player / camera is in P1…
In fact we have developer tools in game for that kind of things. In order to use them, you have to start the map using the devmap command.
When you use Quark, the map automaticaly start with that command.
But you can load any other map with that command. To do so, while you’re in game open the console and type /devmap [mapname]
For example, if you want to use the dev tools on xmas you have to type :
/devmap tc_deadlyxmas
To open the console you have to hit the tilde key. If you don’t know what is the tilde key, open google, type “tilde key” and look the images…
OK ! now you know how to start a map with the devtools enable!
We are going to use a tool called r_showtris.
This tool allow us to see the edge of every polygons in game.
To activate it, you have to type in the console the following command: /r_showtris 1
To disactivate it, type /r_showtris 0
First example video explanation
In this this video, i’ll show you the initial condition. Without any portal.
I run the game then we will saw the famous truck by using /r_showtris 1.
Then i will add a hint brush, rebuild and start the map again.
And boom, no more truck. Pure magic? Nope, knowledge 🙂
You can download the video and the source here:
Beginner error
The first error is to think that we only have make three portals.
So, in our case why not make a simple cube !? It’s easyer to do and we will get the same ! Three portals! Ha ! Simpler and faster to do !
Ok noob let’s test it. Look at this picture:
At this point the only thing i can tell you is to go back to the definition and read it again slowly.
If a direct line can be drawn from a portal (p1) to any other portal (p2) …
Now you can easily understand why i’ve chosen a triangle rather a cube.
Go a step further with the first example
As you saw, i’ve choose to make an isosceles triangle who also have a 90 degree angle to divide the map into portals.
Everything is so mathematicaly prefect, Pythagore my friend!
Ok cool but why? Is it posible to make something less strict?
Yes you can, look at that picture:
The concpet is working but if we zoom closer to the corner, you will see a problem:
The side of our hint brush isn’t adjacent to the corner, there is a littel hole. Therefore, in this case it’s not working.
If we need something less strict we can create two hint brush instead of one to get a portal (P2) with a more complex form.
In this situation, we can have a perfect control over our portal. This method allow us to to have different angles but it add two new portals ( it doesn’t really matter ).
Before going to the second example, we will see how to load into Quark the portals generated during the VIS stage of the compilation.
Loading portal file
The first thing we need to do is to backup the portals into a file when we compile the map.
To do that, you have to go to “Options->configuration”
Then, add “-vis -saveprt” as arguments to the second compile step ( or 2nd buld program )
Once it’s done recompile the map.
And now you can load the .prt file into quark by using this command
That tool alow you to see the portal generated by q3map2. This is very important because q3map choose by itself where to draw portals.
So if you want to control your portals, you need this tool to force q3map to draw portals where you want / need.
Second VIS exemple
This example is not a simple corridor but a square with four distinct aera with roman number.
At this point, please, complie the map to get a new .prt file then load it. You will get something like this:
As you can see, a lot of portals are created without any hint brush.
We will see how and why they are created.
VIS Default behavior
You probably didn’t notice it, but the map is build at the center of the available space in to the editor (quark).
In fact, q3map2 create portals every 1024 units starting from the reference axis (x, y, z).
If you make a test with a wide empty box, you’ll get somthing like this.
You have to know this; sometime it can be disturbing.
In order to keep the second exemple simple, i’m moving the whole map away from the center, then recompile and load agin the .prt file.
As you can see Q3Map2 have build some portals but they’re not accurate. Q3map2 does what it can, but VIS and hint need a human brain.
Now you should ask yourself why Q3map2 have chosen to place the portal this way. Ok, we have a big cube at the center of the map, so it seems logical to use it to create portals. What about the roman numbers?
In fact the brushes of the roman numbers and the big cube aren’t exactly the same: roman numbers are define as “detail brushes” and the big cube is in default behavior “structural brush”.
Structal VS Detail
This is very important and very simple.
Structural brushes create portals.
Detail brushes don’t.
Concretely, here is a result of the same map without details brushes.
I added a staircase to make you better understand the disaster that it results. You can compare with the screenshot just above.
Without the detail brushes, it’s a real mess. You can’t understand what happens when the player is somewhere because there is too many portals. Even worse, some portals are smaller than the player size. It doesn’t make sense, remember the definition. The smallest portals should be larger than the player size.
Therefore all the brushes that are for the decoration mustbe set to detail. Only walls have to be set to the default behavior “structural brush”.
How to set a brush or a group of brushes to detail in Quark
For a single brush
Select it, then do a right click on it “Texture Flags->detail”
For a group of brushes
Select all the brushes. It doesn’t matter if you select them one by one using ctrl+click or only the parent folder. The go to the polyhedron view and change the flags.
Adding hint to the second exemple
In this example i’m showing you a basic mathematical way to do it. But you will have to adapt it to your specific situation.
In this case i’ve choose to divide the hint brushes into 3 groups:
You can download the map here
1 – The Roof
2 – Around the roof
3 – Sides
As you can see, it became a bit more complexe.
To achieve that, you have to think in 3D and it need a bit of trainning.
Aera Portal
Originally the aera portal was created for single player only.
It’s a bad idea to use it in multiplayer.
What are aera portals
Aera portals allow the player to turn on/off hint portals.
In a multiplayer situation, this is realy bad and musn’t be used.
Let’s see a basic exemple.
What we want to do is to hide what is behind the red line.
All what we have to do is to:
- create a door
- add a brush outside the func_door ( but inside the main brush the door ) with a common/texture called aera portal
You can download the source map here
Why is it bad for multiplayer
A sniper is always far away. (Ply1)
A scout is always in front. (Ply2)
Ply2 won’t not see any difference when opening the door.
But the computer of Ply1 (sniper) must render everything in front AND behind Ply2.
Ply2 ( the scoot ) won’t see any differance.
The frame per second of the sniper (Ply2) will fall dramaticaly.
Aera portal is design for single player only and shoudn’t be used for multiplayers.
The famous Leak error
The most common compile error related with VIS is called “leak”.
It happen when vis find a hole that lead to an infinite VIS compile.
This image illustrate how this error happen.
Has you can see Quark automatically show you the path to leak (in red).
In this case the error is caused by the outer walls, that are open.
Now we are going to get shit. We will close the wall, define it as “detail” and recompile the map.
Look at the result.
Because detail walls don’t generate portal, it’s as if they were absent. And then, it leak !
Conculsion
Now you can now build highly detailed map with great performances because you know how it works!
