Why vbsp produces these completely useless visleafs?

Hyperion

L16: Grid Member
aa
Jun 8, 2015
840
659
ZS9TAZ8.jpg

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?
hfoZ9wE.jpg
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
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/
 

henke37

aa
Sep 23, 2011
2,075
515
Remember that vbsp has forced cuts every 256 units. You can also sorta merge visleaves using func_viscluster.
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
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:

Hyperion

L16: Grid Member
aa
Jun 8, 2015
840
659
Does simple visleaves affect more to compile time than actual game performance?
 

Tumby

aa
May 12, 2013
1,084
1,192
every 256 units
every 512 units
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.
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
Does simple visleaves affect more to compile time than actual game performance?
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:

tyler

aa
Sep 11, 2013
5,102
4,621
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.
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.
 
Mar 23, 2013
1,013
347
You can also sorta merge visleaves using func_viscluster.

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.
 
S

saph

You could actually just throw some hint brushes down, you don't need to make those square.

- removed image

This will make those visleafs a lot easier to figure out and much faster in your compile.

Here's an example of some brushwork I hinted rather than func_detailing (I hid all the func_details):

- removed image

In this case, it works just as well if not better to hint along the outer white planks than to func_detail them, because this actually makes visleafs less complex and faster to make during compile. If I f_d these planks, I'd still have to hint here anyway.

Long hallway with windows:

- removed image

These could be areaportaled, but anyone in the area will see in here anyway, so each areaportal's visibility would need to be calculated by the client. It's an example of a situation where putting areaportals in every door/window is a bad idea.

- removed image

Similar thing here. I don't need the doors/windows of that angled building to have areaportals. I also want the deck to not cut visleafs out in the open area (no reason to).

Hope this helps. Simple hints are good hints.

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.
 
Oct 6, 2008
1,947
445
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.
 
S

saph

No, the teal lines aren't the only ones that split.
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 by a moderator:

tyler

aa
Sep 11, 2013
5,102
4,621
Can you guys provide any proof that placing all map geometry into a single quadrant has any impact on anything whatsoever?
It doesn't, that's not accurate. Since all the lines are equally spaced, whether or not you cross the major axes is irrelevant.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
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.

portals1.jpg
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
In this case I'd just hint where the window and door frames are. That'd fix this and speed up your compile time.

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.

u43P1tqkmUwHqLlwdZbb819T6ykfhTHrtAxlSdAzjo0


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:

tyler

aa
Sep 11, 2013
5,102
4,621
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.

u43P1tqkmUwHqLlwdZbb819T6ykfhTHrtAxlSdAzjo0


Note how the window and doorframe eat into the adjacent leafs, but the doorway on the right doesn't. That's the executable working its math in a particular direction through the space.

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:

wrz3h9N.png


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.
 
Last edited:

tyler

aa
Sep 11, 2013
5,102
4,621
Wow I just found this. On the inside where I didn't hint?

9ABGMbN.jpg


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