Long compile times

Exactol

Certified Hammer Hacker
aa
Jul 11, 2013
421
537
I'm trying to compile a map, but the compile times are crazy. It can run fast vis fine, but not normal. I have my map decently optimized. I know that in the past people have complained that I did too much func_detailing and it caused lag. Any tips? I'm hopeless at hint and skip, so thats probably out of the picture.
 

Beetle

L9: Fashionable Member
Aug 17, 2008
627
178
as far as I know overdoing the func_details would cause lag but not long compile times.
 

Snowbat

L4: Comfortable Member
Apr 23, 2013
165
74
Long compile times are different than in game lag.
Do you happen to have big open rooms? Large areas with uninterrupted visibility are a pain to compile. If so, you can speed up compile times by using func_visclusters or, if the big open area isn't an area players can interact with, turn that into a 3D skybox.
 

wareya

L420: High Member
Jun 17, 2012
493
191
Hint and skip are a game time optimization, vis doesn't usually do stuff that makes them make it compile faster. So what I want to say is that you should be using vis clusters for any large open or tall areas you have, especially ones with complicated geometry. Just make sure not to touch places that definitely can't see eachother with them, like two sides of a skybox brush.
 

Freyja

aa
Jul 31, 2009
2,994
5,813
No, hint and skip, if placed correctly, can drastically alter compile times (in either way).

The reason VVIS slows down is because it's doing calculations on which visleaves can see which other visleaves when a player is standing in the first visleaf. As you can imagine, with the map getting larger, this calculation expands exponentially.

VBSP is the process that creates these visleaves. It does this the best it can by seeing what solid brushes you have and cutting the map around those. It ignores func_details, any other point or brush entity, and some tool textures like clip.

Imagine this scenario, you have this room with a wall through it and a door in said wall:

visleaf1.jpg


Now, VBSP could cut it in either of these ways, which way it does really depends on surrounding visleaves.

visleaf2.jpg

visleaf3.jpg


As you can see, the first method only has 3 visleaves, and the second has 5. 5 isn't going to be a terribly large increase in compile time, but on a much grander scale, with more complex systems, it adds up.

This is where Hint textures come in. They tell VBSP to cut a visleaf along the hint texture. You use skip on all other faces as skip is completely ignored during compile, as to not tell VBSP to cut on every face of your brush. Putting a bush in the doorway and texturing both faces with hint will make sure that VBSP cuts it in the first method. I don't recommend doing this for EVERY DOORWAY, but it can certainly help sometimes.

So, imagine for a second that your map is being cut the second way. This is taking twice as long to compile because of the increased complexity in visleaves. Instead of using hint brushes, you could use Visclusters.

func_viscluster is a volume that tells VVIS that any visleaves it touches can see each other at all times.

Imagine that we have this scenario. The blue dot is the player, the cone is where he or she is looking.

visleaf4.jpg


VBSP could cut it like this:

visleaf5.jpg


From the player's position (more specifically, the visleaf they are standing in. Source does not care about which direction they are facing), they can see these visleaves:

visleaf6.jpg


As you can see, VVIS might only take a second to figure out that these are the leaves to render when the player is standing in said place, but it has to do this for EVERY visleaf in your map. It takes a long time.

So, we take this situation and put in a viscluster here (keeping in mind this is a pretty terrible example)

visleaf7.jpg


Now, when VVIS gets to calculating which visleaves the player can see, it goes 'Oh, well, they can see a visleaf with a viscluster touching it. That means every other visleaf touching that viscluster can be seen too, so I don't have to worry about those calculations'.

This is extremely useful for big open areas (like the middle of 2fort, 2nd on badlands) where a player can see all of it at once, it cuts down on compile times SIGNIFICANTLY as it throws out a lot of the calculations.

However, it assumes these things because you told it to. If used badly, this means a lot can be rendered that the player can't see.

Used together, hints and skips can drastically reduce your compile time. Hints are more effective at in-game optimisation, it's true, but they can be used to great power in reducing compile times.
 

wareya

L420: High Member
Jun 17, 2012
493
191
I always thought that ingame optimization by *adding* portals was the primary use of hint:
https://dl.dropboxusercontent.com/u/1811521/dgerdf.png
Mostly speaking, cutting visleafs in ways which prevent them from "peaking" around corners that tend to have a lot of stuff behind them. Of course, it's not entirely necessary if you have areaportals in the doors or corners, but VIS is so much cheaper at runtime than areaportals are, and it's very useful to have this kind of culling between major areas.

A lot of the portal cutting that BSP does that ends up messy that you can fix with hints usually has some nice visibility effect to it, though there *are* cases where it can make complex portals that VIS sucks at and you can simplify with hints. Regardless, I still recommend viscluster for areas with incredibly complex or many portals to reduce compile times, instead of hint, because it's much more predictable.

That being said, where you want to use hint depends almost entirely on the map and its complexity in the first place. For example, viaduct has a massive horizontal hint on equal level with the hill (or the nodraw block under it) so that visleafs aren't made which would see from one bottom of the hill to the other bottom of the hill. On the other hand, 2fort's geometry is so terrible that hints are basically necessary to keep the complexity of the portals it generates in check. So, as for whether to reduce or increase the portals in an area with hint, it depends on exactly what's going on in that area in the first place.

Finally, in your very last image, the visleaf that the player is in can actually see every single visleaf in the image, even if the player theirself can only actually *see* the ones you marked yes -- I mean, unless you have an areaportal in that door they're looking at, for some reason.
 

Freyja

aa
Jul 31, 2009
2,994
5,813
No, the player cannot. That is not how visleaves work. The black is a solid wall, we assume it goes from the floor to the roof.

EDIT: Okay you're right, that wasn't intentional. However it's not really the point of the image :p
 
Last edited:

Exactol

Certified Hammer Hacker
aa
Jul 11, 2013
421
537
Yea, its got big open areas, I cannot believe i forgot func_viscluster
 

Snowbat

L4: Comfortable Member
Apr 23, 2013
165
74
Excellent info, Aly.
I knew about visclusters, but I couldn't have explained it better myself and you also mentioned a very important point: improperly used visclusters can cause poor performance in game.
The thing is to only use visclusters when you're 101% sure the areas the visclusters touches can all see each other (telling VVIS to ignore calculation and just assume all can see all)
 
Mar 23, 2013
1,013
347
wall of text

I think the last two pictures are incorrect.
After my experience: not only the viscleaf which can be seen by the player are rendered, also the visleaf which are "seen" by the visleaf you are standing in are rendered.
What it means all visleafes which can have a stright line between the visleaf and the leaf you are standing in are rendered. Like this:

c0i8.jpg


since the visleaf in which the player is can "see" the other visleafs (new blue line) and therefore I marked the other two with "yes" as well.
 
Last edited:

Freyja

aa
Jul 31, 2009
2,994
5,813
Yeah I know that's what wareya was saying. It's a really bad example, but the point of the image still stands.
 

UKCS-Alias

Mann vs Machine... or... Mapper vs Meta?
aa
Sep 8, 2008
1,264
816
There is also the order of deciding which happens. Hinting happens early in the process, so it can even be usefull to reduce the leafs it creates in the first place instead of using a viscluster to fix it after. A hint is able to reduce the leaves since they are placed before the normal leaf cutting happens.

A hint is used in vbsp to create leaves. A viscluster is used in vvis (i think this also happens in step 1 since this is a fast to perform step). What a viscluster doesnt stop is the game deciding each leaf on what to draw. The output might be the same for each leaf, but each transition it still has to read which leafs to draw.

To me visclusters should be avoided on ground level and prevent to touch the walls of the doorway. If you take the whole 2fort middle then when you are on ground level you want to reduce the chance it draws something from the top level at the inside. But you want to prevent it from having to calculate all the leafs in the sky since that area is used less. And when you are in the sky, you want to avoid some tunnel partss being drawns.

Obviously, from that side it might be minimal, but now immagine if you are inside and it spots the outside cluster. That will be far more extreme.

That it has to calculate 20 extra leafs realy doesnt matter if you reduced 80 leafs instead of 100. Those 20 still have some use on optimizing. And if you still want to reduce that, just make it 2 clusters.

For example on this image immagine standing at purple spots and the outcome in the leafs it draws: https://dl.dropboxusercontent.com/u/2070422/visclusters.png
(still a poor example, but its about that minimal performance bit which with bad luck can make situations worse by far)