Very long compile on VVIS (Source)

[Rokusho39]

During my map compiling, it will comfortable do the VBSP and VRAD quite quickly with HDR (around 30 min). However, because I didn't do the VVIS, the map runs very poorly. I have tried looking at various optimisation guides and have tried my best to optimise my map as much as possible. However as I normally do small maps I have very little experience with optimisation.

Recently, I have tried to compile fully and even after 12 hours, the VVIS was only just over 40%. Should it take this long? Is there anything anyone can suggest? Any help at all will be greatly appreciated.

[insta]

The more complex the bsp file, the longer the vis will take to complete. Convert anything that isn't blocking visibility for the player or sealing the map against the void into func_detail, keep the amount of regular brushes to a minimum to make it easier for vvis to figure out just what needs to be calculated.

[dissonance]

and make sure your skybox is as small as possible. block out areas the player can't get to (rooftops, alleys, etc) with playerclip.

[Defrag]

If it's taking anything approaching an hour I'd be concerned, even with a big map. Your goal is to basically make your base map geometry as simple as possible. Anything that is small or doesn't contribute to visibility blocking should be func_detailed. Slanted geometry can usually also be optimised.

The chances are that you've got some crazy BSP cuts going on somewhere and it's causing a lot of vis errors which creates a much more complex visibility set, causing the compile time to be vastly inflated. Run BSP and output to glview (check the valve wiki if you don't know what I mean), then open glview and look for the high-complexity areas where the leaf complexity / density is all wrong. This is the absolute best way to spot problem areas and oversights.

I use a .bat file to compile the map & run glview. I save a .vmf to "latest.vmf" then run this:

cd "X:\Valve\Steam\SteamApps\youraccountname\sourcesdk\bin"

vbsp.exe -glview "X:\Valve\Steam\SteamApps\youraccountname\sourcesdk_content\modname\mapsrc\latest.vmf"

glview.exe -portals "X:\Valve\Steam\SteamApps\youraccountname\sourcesdk_content\modname\mapsrc\latest.gl"

pause

Obviously change the paths & modname to match your own directories.

[NykO18]

If it's taking anything approaching an hour I'd be concerned, even with a big map.

Well.. try to make a map with a large natural and irregular exterior with houses and a sewer network just under, composed of cylindrical rooms cut by cylindrical tunnels at 45°. The VVIS will pass a really hard time trying to figure out what's happening in there. And when compiled even if the compilation last 7 or 8 hours, it doesn't bug or whatever, everything's normal.

Like you, I think that for "classic maps", VVIS should not last longer that one hour. But in some other case, it seems to be inevitable.

[dissonance]

yeah, why is it that vis shits itself when you use anything other than a 90 degree angle? you'd think they'd be able to code that sort of thing in.

[Skjalg]

Because it has to break up the floor and ceiling more

[Rokusho39]

Well, I have alredy func_detailed everything that isn't blocking the line of sight of players. I think my main problem is the skybox, I simply put a square one that surrounded the entire map...

My map is also based on a town in the same style as de_italy, so there was a lot of sloping roofs and plenty on non-90 degree geometry kicking about. It is also mostly multi leveled, probably screwing the VVIS up. Sigh.

I'll be having a whack at fixing it during this week. Cheers for the feedback.

[insta]

A good trick is to go into Autovisgroups and turn off props, func_details and entities in general, so that you're left with only the world brushes. That should give you a better understanding of what vis has to deal with, and it makes it easier to spot stuff which can be optimized.

[Steppenwolf]

Never use brushes with a angle other then 90 degrees for vis blocking! It only causes trouble and increases compile times.

For a tunnel just make a very simple cubic outside cage. Then make a detailed inside that can have 45 degress stuff or whatever. but make this inside func_details!

Cut large outside areas in sections via hint brushes to decrease compile times.

The vis of a perfectly optimized map no matter how large and detailed shouldn't compile longer then 15 minutes in -normal mode.

edit:

This pic shows the brushwork that i use for visblocking in one of my maps. it should give you an impression of how simplistic a good static brushwork is. All building details and angled stuff is func_details!

Thats how detailed the map looks ingame:

After extreme optimizing with the help of glview the vis compile time is at around 5 minutes.

[Defrag]

If it's taking anything approaching an hour I'd be concerned, even with a big map.

Well.. try to make a map with a large natural and irregular exterior with houses and a sewer network just under, composed of cylindrical rooms cut by cylindrical tunnels at 45°. The VVIS will pass a really hard time trying to figure out what's happening in there. And when compiled even if the compilation last 7 or 8 hours, it doesn't bug or whatever, everything's normal.

Like you, I think that for "classic maps", VVIS should not last longer that one hour. But in some other case, it seems to be inevitable.

Like SW said, there are ways to get around a lot of these problems. In many cases you use world brushes at right angles and make up the rest of the shapes using func_details while achieving the exact same visuals.

I wrote a dev journal on this ages ago, you can find it here:

http://www.fortress-forever.com/?a=devj (near the foot of the page).

Some pics along the same lines as SW's:

http://www.fortress-forever.com/~defrag ... e_full.jpg

http://www.fortress-forever.com/~defrag ... _empty.jpg

http://www.fortress-forever.com/~defrag ... ything.jpg

http://www.fortress-forever.com/~defrag ... etails.jpg

[NykO18]

Hey, I know what func_detailling means.

But, when half of the map is made of cylindrical tunnels, it's not really a good idea to shape it quickly inside cubic rooms. Especially when there's an insane amount of detail and expensive water.

I prefer waiting 7 or 8 hours (night compiling) and getting better FPS than doing a one hour compile and getting crapy vis-blocking.

But, in 95% of all cases, I agree that its the good solution. I was just saying that it's not always possible.

[hessi]

uhm. your fps will be much lower with a complex leaf structure. so i'd still recommend the workflow steppenwolf did point up (which is indeed the best way to optimize).

[Steppenwolf]

Hey, I know what func_detailling means.

But, when half of the map is made of cylindrical tunnels, it's not really a good idea to shape it quickly inside cubic rooms. Especially when there's an insane amount of detail and expensive water.

I prefer waiting 7 or 8 hours (night compiling) and getting better FPS than doing a one hour compile and getting crapy vis-blocking.

But, in 95% of all cases, I agree that its the good solution. I was just saying that it's not always possible.

I hope this helps you to understand. You basicaly map a very simplified version of your tunnel around. The real tunnel, which is visible ingame is completely made of func_detail brushes.

[NykO18]

Yeah, I agree. But with a 10 faces tunnel like mine, if you add a cubic shape outside, it adds 4 faces.. 40%. I think that adding faces just to shorten the compilation time isn't a good idea, especially when VVIS manages to make "cylindrical" vis-leaves at last. I don't think that's a problem.

Also, isn't the lightning way much crappier on func_details ?

Anyway, it's a trick I often used on my past maps and I tend on not using it anymore. Don't know why, I think I'm giving to much hope in VVIS.