Why vbsp produces these completely useless visleafs?

Discussion in 'Mapping Questions & Discussion' started by Hyperion, Oct 1, 2015.

  1. Hyperion

    aa Hyperion L16: Grid Member

    Messages:
    810
    Positive Ratings:
    618
    [​IMG]
    I'm trying to optimize my map but I cant simplify those visleafs at all! As you can see there is few hint brushes which help little bit. Is there any way to stop vbsp making those weird visleafs?

    Second example: why that tunnel is cut in the middle?[​IMG]
     
  2. worMatty

    aa worMatty Repacking Evangelist

    Messages:
    1,072
    Positive Ratings:
    836
    Unfortunately VBSP likes giving you portals. There isn't much you can do to reduce them, and it would be a waste of time trying to. You should ignore it, as it is extremely unlikely to negatively affect performance. In fact the leaves in your first screenshot will probably help reduce the amount of stuff that's being rendered, sometimes, at some angles and distances.

    Don't worry about them. They look messy and that feels bad but they are probably doing a great job for you and addressing them would be a pointless chunk of dev time you haven't got.

    tyler posted some great screenshots yesterday of how he uses hint faces to pre-empt VBSP sometimes: http://tf2maps.net/posts/344228/
     
  3. henke37

    aa henke37

    Messages:
    1,955
    Positive Ratings:
    465
    Remember that vbsp has forced cuts every 256 units. You can also sorta merge visleaves using func_viscluster.
     
  4. worMatty

    aa worMatty Repacking Evangelist

    Messages:
    1,072
    Positive Ratings:
    836
    Thankfully Henke, it's every 1024 [edited] units. It follows the red and green lines on the Hammer grid. Though, not horizontally. Only along X and Y.

    func_viscluster is good for very large open spaces where every visleaf in an area is guaranteed to be rendered all at once. It cuts down VVIS calculations because it tells VVIS not to bother calculating visibility between each of the visleaves touched by the func_viscluster, but when used without a good understanding of how visleaves work, can adversely affect rendering performance. In small spaces like the ones above, where there will be player traffic, it's best to leave them alone as they can be surprisingly useful.
     
    Last edited: Oct 1, 2015
  5. Hyperion

    aa Hyperion L16: Grid Member

    Messages:
    810
    Positive Ratings:
    618
    Does simple visleaves affect more to compile time than actual game performance?
     
  6. Tumbolisu

    aa Tumbolisu  I ⌄ I 

    Messages:
    960
    Positive Ratings:
    949
    Lmao, still wrong. It's every 1024 units. The other things about this are correct.

    Func_viscluster is not meant to "merge" visleafs just for the sake of simplfying the visleafs. It's used to reduce compile time and make sure that multiple areas will be loaded together even if normaly they wouldn't.
    I have not yet seen any proof that func_viscluster can increase performance.

    Now back to the images. If you take a single one of the strangely placed portals, is there any wall or hint in your map that is on the exact same plane? Anything can affect visleaf generation even when not directly connected to it. Because of this you will need to place more hints and consider the placement of all of them more carefully.


    And here is something I noticed while playing your map (which is also shown in the first screenshot of yours):
    Image01.jpg
    [Image 1]
    Image02.jpg
    [Image 2]

    In image 1 and 2 I biult a simplified version of the map geometry. Image 2 shows the func_detailed roof. This means that anybod standing on top of the roof, or potentialy even just in front of the building, will have the entire area behind the brick wall loaded. This is bad.
    It's possible to change this without really affecting the number of visleafs. what need's ti happen is this:
    Image03.jpg
    [Image 3]
    Here the red marked brushes are func_detail, everything else is not. This means that If you place area_portals in the doorways, anybody standing on top or next to the building will have much less stuff rendered. The only thing left to do is creating a "bounding box" brush on the sloped roof and using hint textures on the outside. Otherwise vbsp may do very stupid cuts.
    I hope this will help with your map optimization.
     
  7. worMatty

    aa worMatty Repacking Evangelist

    Messages:
    1,072
    Positive Ratings:
    836
    Correct. VBSP generates visleaves. VVIS checks which visleaves each visleaf can see. The larger the number of visleaves, the more time VVIS has to spend checking them all.

    This is why fast compiles are a bad idea if you plan to have people play test a detailed map. VVIS doesn't check visibility in a fast compile.

    EDIT: My apologies. The mandatory portals VBSP creates are every 1024 units, along X and Y in the top-down 2D viewport, following the red and green lines. Thanks, Tumbolisu for eagerly pointing that out.
     
    Last edited: Oct 1, 2015
  8. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    4,499
    I'd really recommend against using these unless you're very well versed in optimization. It's quite easy to unintentionally cause a very large area to render from a position where it shouldn't because of func_viscluster. Most the application of visclusters is in skybox areas or out of bounds areas, if ever. I'd say more but I'm running out the door and just want to make sure no one uses this entity without a proper understanding of it.
     
  9. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    341
    fimc_viscluster only tell hammer which leafs can see eachother. It does NOT merge visleaves even if the portal file sometimes looks like it did merge them, this actually didn't happen and is not true in game. It's a really weird bug.
     
  10. saph

    aa saph seventeen shades of various blues

    Messages:
    169
    Positive Ratings:
    318
    I would definitely lean towards what tyler said, hints and skips are an easy way to manipulate visleafs, but it takes practice. Most of the time, simple hints are good hints, but you might also want to try the high dark magic of occluders. For doublecap, it's very open in some areas, with narrow connectors. This chokes the visleafs, making it want to calculate more. Make sure you have the map in one quadrant of the grid because during compile, the teal lines will automatically split visleafs there, so having a single quadrant will reduce numportals, improving performance. Just play around with your layout if optimization doesn't work for you because it might be the layout causing the issues.
     
  11. Tumbolisu

    aa Tumbolisu  I ⌄ I 

    Messages:
    960
    Positive Ratings:
    949
    No, the teal lines aren't the only ones that split. Like worMatty has already said:
     
  12. Kill_the_Bug

    aa Kill_the_Bug

    Messages:
    1,503
    Positive Ratings:
    322
    What can also cut down on them is to, if possible, get your map into 1 quadrant of the grid (if it fits) in you top view and your side/font view. Crossing the threshold into other areas will also cause extra items to occur.
     
  13. saph

    aa saph seventeen shades of various blues

    Messages:
    169
    Positive Ratings:
    318
    I know they split every 1024 units, but a common issue is that people have an open area directly on the teal line, creating even more numportals. If you take if off the teal line, you can reduce the number drastically. Also, @MrHyperion, it's good that you made a 3D skybox instead of just a cube, but make sure you check it out to see if you can plop a hint-skip from the floor to ceiling. Try playing around with mat_wireframe 1 to see if any diagonal hint-skip brushes would be useful. Make sure you keep your numportal amount under 4,000. It caps around there because it's too much to calculate.
     
    Last edited: Oct 1, 2015
  14. Tumbolisu

    aa Tumbolisu  I ⌄ I 

    Messages:
    960
    Positive Ratings:
    949
    Can you guys provide any proof that placing all map geometry into a single quadrant has any impact on anything whatsoever?
     
  15. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    4,499
    It doesn't, that's not accurate. Since all the lines are equally spaced, whether or not you cross the major axes is irrelevant.
     
  16. grazr

    aa grazr Old Man Mutant Ninja Turtle

    Messages:
    5,436
    Positive Ratings:
    3,768
    In some cases it's unfortunate that there is a methodology to the order in which leafs are created. That means sometimes geometry which should only otherwise create 2 leaves, say, a leaf adjacent to a wall and a leaf inside a crevice cut out to insert a window frame model causes that crevice to project outwards into the world, creating 6-8 leaves where there could be 2. The only way to address this is to rotate the map 90 degrees, but depending on how you've detailed the map, it will only make different geometry elsewhere do the same thing.

    If you've stripped the map geometry down to its basic elements, a couple extra leafs, although ugly, really wont have much impact on compile time or game performance. It's just OCD on our part.

    [​IMG]
     
  17. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    4,499
    In this case I'd just hint where the window and door frames are. That'd fix this and speed up your compile time.
     
  18. grazr

    aa grazr Old Man Mutant Ninja Turtle

    Messages:
    5,436
    Positive Ratings:
    3,768
    No it wouldn't, because they already are. That's what i'm saying. There's an order to the way the engine works these things out and once it's cut a leaf, that's it, it carries on created that set of micro leaves.

    [​IMG]

    Note how the window and doorframe eat into the adjacent leaves, but the doorway on the right doesn't. That's the executable working its math in a particular direction through the 3d space.
     
    Last edited: Oct 1, 2015
  19. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    4,499
    Yes, but how you place the hint brushes makes them behave differently. You can place a large hint brush across the entire face of the building to eliminate those portals being cast off from the door and window frame.

    Here's the same idea with a similar issue:

    [​IMG]

    You can actually see how VVIS is skipping over where that window is and only cutting where I have different brushes stacked on each other. I should pull this hint brush down to simplify this further, actually. (The double lines on the vertical sides are because I'm 16u to the side of a major grid line and there's something out of frame doing that, not because of the brushwork visible here.)

    It's not about filling a hole with hint brushes. You have to make it a big brush so VVIS knows where to cut and what not to cross.
     
    • Thanks Thanks x 1
    Last edited: Oct 1, 2015
  20. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    4,499
    Wow I just found this. On the inside where I didn't hint?

    [​IMG]

    Exactly what you have, grazr. Notice the horizontal cut.
     
    Last edited: Oct 1, 2015