View Full Version : Area Portals and Hint Brushes

09-26-2002, 01:29 PM
In my junk file it tells me this about an areaportal I've placed in a door way.

WARNING: areaportal brush 1469 doesn't touch two areas

It's in the door and it covers the whole door space area plus it doesn't seem to speed up the level either. My door is not square but does this matter?

I also have a question about hint brushes. I've read some tutorials but I don't really know how to intergrate them into my level. The thing is when I reach the last room I constructed and turn to face the way I came into the room it seems to render all the level I've just been through which is quite large. So does hint brushes enable me to stop it from doing that and do I have to place them in corners in corridors or place on the ceiling in my last room to stop it from rendering the upper parts that are further away. Sorry if I've confused you but I'm confused myself about this.

Can anyone shed light on this!

09-26-2002, 02:16 PM
k make sure the brushes surrounding your door are all structural; the shape doesn't matter. then the area portal should touch all these structural brushes. if it does, chances are one of those brushes it touches is not structruall

k i'll take a stab at explaining hint brushes. its just another way of saying what is in all the hint brush tuts i read. maybe it will help.
When a map compiles, the first thing it does is divide it into what's called "convex volumes". This means simply an area that has six non-paralell volumes or planes - a cube. The compiler will start outside and work inwards. It will first make one giant single volume, then start splitting that up into smaller volumes. The term for these volumes are called "leaf nodes". The more leaf nodes, the longer the compile time.
The compiler finds a structural plane (one face of a structural brush), and travels along that face until it intersects another structural brush, at which point it will continue to the next and the next until it finds itself enclosed by six nonparallel faces, then creates a leaf node. The compiler in this process ignores detail brushes, for they are not involved in determining the making of a leaf node. That is why the balancing of structural and detail brushes is so important. The process will first use structural planes that are perpendicular to the axes (x,y,z), then move on to non perpendicular planes to create leaf nodes.
If you end up with a large leaf node, it will also be filled with a large amount of triangles, which will make the game work extra hard to render everything in real time. Every time you move in the slightest way, the perspective of the player changes, and the game has to redraw every triangle with all its parameters to keep up. And if you have triangles behind triangles, even though you can't see them, for example you can't see into the other room, the game will still try to render all those triangles in the other room. Unless of coarse the wall separating the room is a structural brush, or it is an area portal inside door brushes.

So you have a large leaf node with a large amount of triangles trying to be drawn, here is where hint brushes come in. It is basically a “nodraw” structural brush designed to attract the attention of the compiler saying "hey here is a structural brush so divide the map into a leaf node here". That way the leaf node will be smaller, containing fewer triangles, and hence improving fps. But the reason people say they don't always work is because the compiler may not decide to use your hint brush you placed to divide into a leaf node. So the strategic placement of the hint brush in relation to the structural brushes near it is a major factor, especially when the surrounding structural brushes are not perpendicular to any axes. In fact, the compiler starts on the outside attempting to divide the map into leaf nodes in 128 unit increments if it can, and may ignore a hint brush that is placed in between. Consequently, these leaf nodes can overlap, and often do, but I'll explain portals first.

Portals are areas that connect leaf nodes, in other words, if one leaf node created has an opening like a doorway for example, it can technically "see" into the leaf node adjacent to it, so a portal is created between the two. This information is stored in the *.prt file. In fact, many leaf nodes can be visible, or see through, to other leaf nodes. Portals are created when leaf nodes are interrupted by structural brushes, like a wall blocking your view. Also, since leaf nodes overlap, a brush face can be a part of more than one leaf node, so this brush face, which is visible to several leaf nodes, will be drawn for every node the player occupies. Lets say you are standing in a room, and you are in a spot where three leaf nodes overlap. Now lets say that these three leaf nodes you occupy, can see through to other leaf nodes. Lets say one of the leaf nodes you occupy can see through to three other leaf nodes, and lets assume that for the remaining two leaf nodes you are occupying as well. Hence, the three leaf nodes you are occupying can collectively see into nine other leaf nodes. All the triangles within all these nodes will be drawn whether you can see them or not. That is a lot of triangles. By the way, when you use fast vis, every portal is visible to the other, so you can expect lower fps with fast vis. It's fast because it doesn't create a *.prt file.

Structural and hint brushes effectively "block vis" or make it so one node can't see the other, to prevent the other node's triangles from being drawn when you are standing in an adjacent node. So the trick is to have the fewest amount of nodes visible to other nodes. You also want to avoid large leaf nodes which will draw a lot of triangles. An inefficient arrangement of leaf nodes will also reduce fps. The downside is, the higher the number of leaf nodes and portals, the longer the compile time, and it will increase exponentially.

09-30-2002, 02:42 PM
That's a good definition Bell. It helped me alot. Thanks