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?
every 256 units
Lmao, still wrong. It's every 1024 units. The other things about this are correct.every 512 units
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.Does simple visleaves affect more to compile time than actual game performance?
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.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.
You can also sorta merge visleaves using func_viscluster.
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.
It follows the red and green lines on the Hammer grid. Though, not horizontally. Only along X and Y.
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.No, the teal lines aren't the only ones that split.
It doesn't, that's not accurate. Since all the lines are equally spaced, whether or not you cross the major axes is irrelevant.Can you guys provide any proof that placing all map geometry into a single quadrant has any impact on anything whatsoever?
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.
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.