A very short primer on hint brushes

wareya

L420: High Member
Jun 17, 2012
493
191
This is a very simple explanation of how visibility works in TF2 and how you can control it on a very basic level (with hint brushes).

First of all, when you compile a map, the compiler splits the map up into a bunch of convex partitions.

A map could look like this:
y9U8xAt.png

And a simplified version of its partitions could look like this:
24F8bwc.png

It makes some choices that don't seem to make sense, but that's because the way it partitions the map is *very* procedural.

Anyway, let's pretend you have two players on the map at the positions of the orange dots:
O7JokNJ.png

They "belong" to the partitions that they're inside of, and the purple line shows that the partitions can "see" eachother. This is how the compiler deals with what parts of the map can see what other parts of the map. If it can make a line through nothing but partitions (that is, it doesn't go through a solid brush or the void) to connect two partitions, then anything in one of those partitions will render if the camera is in the other one.

Fortunately, you can constrain partitions with hint brushes, like putting one on the blue line here:
vSiUQKH.png

(note that you only need a single face, and the ones you don't want to "cut" leafs/partitions should be textured as "skip")
Which brings us to this case where the orange dots *can't* see eachother:
KSFtAJO.png

There's no line you can draw between those two partitions/leafs without going through solid geometry, so they can't see eachother.

Note that adding the visleaf caused one of the automatic separations to change. I put this really nearby, but it can actually happen anywhere, so you would probably want to put a hint on the right side of that building in the middle too.

Note that if you go way overboard with hint brushes you can make your map take much much longer to compile. Having a long compile doesn't mean your map isn't optimized ingame, but it's something you want to avoid because it's really annoying and makes testing things harder or take more effort than it should. Until you get a real good hang of them, you should only use them in important places where it really helps.
 
Last edited:

henke37

aa
Sep 23, 2011
2,075
515
Do note that the use of hint brushes might cause the automatic areas to be different. Hint brushes are processed before the automatic cutting begins.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Also worth remembering: higher vvis compile times doesn't mean your map is poorly optimised. After adding areaportals and the necessary hint brushes to pl_halfacre it went from about 50 seconds to around 7 minutes for vvis to run, but the framerates rose dramatically for players.
 
Last edited:

Fruity Snacks

Creator of blackholes & memes. Destroyer of forums
aa
Sep 5, 2010
6,394
5,571
Also worth remembering: higher vvis compile times doesn't mean your map is poorly optimised. After adding areaportals and the necessary hint brushes to pl_halfacre it went from about 50 seconds to around 7 minutes for vvis to run, but the framerates dropped dramatically for players.

Isn't framerates dropping dramatically... a bad thing?
 

xzzy

aa
Jan 30, 2010
815
531
High vvis times on a detailed map makes a good opportunity for investigation though. Let vvis run, and load the portal file in hammer. Look for huge masses of blue lines and analyze them for conversion to detail brushes.

That's typically how I find things I forgot to ctrl+t.
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
High vvis times on a detailed map makes a good opportunity for investigation though. Let vvis run, and load the portal file in hammer. Look for huge masses of blue lines and analyze them for conversion to detail brushes.

That's typically how I find things I forgot to ctrl+t.
That's good to do if the compile already happened, but for preventative measures I find that by turning off all visgroups that don't affect leaves it becomes just as obvious what is forgotten. (I tend to do that whenever I do anything related to vis optimizing)
 

henke37

aa
Sep 23, 2011
2,075
515
One can somewhat combat long vvis times using visclusters. They act as a shortcut for vvis by saying "yup, all of these can see each other, move on".
 

wareya

L420: High Member
Jun 17, 2012
493
191
They also say "anything that can see any of these can see all of them" (except w/r/t areaportals). If only there were something that only did what you described.
 

wareya

L420: High Member
Jun 17, 2012
493
191
Partitions and leafs are very closely related. They're ALMOST the same thing.

I'm basing the usage of "partition" based off some random line of source engine code though so don't quote me.
 
Last edited:

Freyja

aa
Jul 31, 2009
2,994
5,813
Also for some reason VBSP always cuts vis along the origin lines (the teal ones) no matter the visleaf sizing around it. Not quite sure why. Good to keep in mind.
 

puxorb

L69: Emoticon
aa
Dec 15, 2013
531
798
Also for some reason VBSP always cuts vis along the origin lines (the teal ones) no matter the visleaf sizing around it. Not quite sure why. Good to keep in mind.

Huh. I never knew that, I guess it would explain a lot. So does this mean we should try to build our maps off center? Preferably in one of the quadrants?
 

Freyja

aa
Jul 31, 2009
2,994
5,813
I thought that visleafs cut with the 1024 rule whenever they got over 1024, not every 1024 units of the grid. But I must admit I've never really taken much notice.
 

henke37

aa
Sep 23, 2011
2,075
515
It follows the grid, starting out at origo (0,0), Hammer even color codes the grid to let you know where the forced slices are.