A very short primer on hint brushes

Discussion in 'Tutorials & Resources' started by wareya, May 28, 2014.

  1. wareya

    wareya L7: Fancy Member

    Messages:
    493
    Positive Ratings:
    173
    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:
    [​IMG]
    And a simplified version of its partitions could look like this:
    [​IMG]
    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:
    [​IMG]
    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:
    [​IMG]
    (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:
    [​IMG]
    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.
     
    • Thanks Thanks x 2
    Last edited: May 29, 2014
  2. henke37

    aa henke37

    Messages:
    1,921
    Positive Ratings:
    450
    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.
     
  3. YM

    aa YM LVL100 YM

    Messages:
    7,099
    Positive Ratings:
    5,745
    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: May 29, 2014
  4. Fr0Z3nR

    aa Fr0Z3nR Creator of blackholes & memes. Destroyer of forums

    Messages:
    6,391
    Positive Ratings:
    4,906
    Isn't framerates dropping dramatically... a bad thing?
     
    • Thanks Thanks x 1
  5. YM

    aa YM LVL100 YM

    Messages:
    7,099
    Positive Ratings:
    5,745
    shush you. Lag dropped. fps rose.
     
  6. Faux Rhinoceros

    aa Faux Rhinoceros Also known as Dr. Element

    Messages:
    1,479
    Positive Ratings:
    1,369
  7. xzzy

    aa xzzy

    Messages:
    815
    Positive Ratings:
    393
    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.
     
  8. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,535
    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)
     
  9. wareya

    wareya L7: Fancy Member

    Messages:
    493
    Positive Ratings:
    173
    Edited according to advice/feedback.
     
  10. henke37

    aa henke37

    Messages:
    1,921
    Positive Ratings:
    450
    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".
     
  11. wareya

    wareya L7: Fancy Member

    Messages:
    493
    Positive Ratings:
    173
    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.
     
  12. littleedge

    aa littleedge L1111: Clipping Guru

    Messages:
    983
    Positive Ratings:
    573
    Isn't it also true that the blue and brown grid lines in Hammer are where vvis automatically places a "partition" as you called it?
     
  13. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,535
    Yes. Leaves will be sliced every 1024 units no matter what.
     
  14. wareya

    wareya L7: Fancy Member

    Messages:
    493
    Positive Ratings:
    173
    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: May 31, 2014
  15. Freyja

    aa Freyja ¯\_(ツ)_/¯

    Messages:
    2,878
    Positive Ratings:
    4,955
    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.
     
  16. puxorb

    aa puxorb L69: Emoticon

    Messages:
    455
    Positive Ratings:
    643
    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?
     
  17. A Boojum Snark

    aa A Boojum Snark Toraipoddodezain Mazahabado

    Messages:
    4,769
    Positive Ratings:
    5,535
    Because the 0 is a multiple of 1024.
     
  18. Freyja

    aa Freyja ¯\_(ツ)_/¯

    Messages:
    2,878
    Positive Ratings:
    4,955
    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.
     
  19. henke37

    aa henke37

    Messages:
    1,921
    Positive Ratings:
    450
    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.
     
  20. littleedge

    aa littleedge L1111: Clipping Guru

    Messages:
    983
    Positive Ratings:
    573
    Yeah. (0,0,0) is a multiple of 1024. It's just colored differently for the fast identification of the axes.