Very long compile on VVIS (Source)

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.

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

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:

Quote

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.

Quote from 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.

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.

Because it has to break up the floor and ceiling more

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.

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!

[Blocked Image: http://img504.imageshack.us/img504/4062/wuerfelsf6.jpg]

Thats how detailed the map looks ingame:

[Blocked Image: http://i23.photobucket.com/albums/b382/HCU/Mods/Insurgency/ins_baghdad_feb06_03.jpg]

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

Quote from NykO18

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

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.

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

Quote from 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.

[Blocked Image: http://img409.imageshack.us/img409/198/vistunnelrk0.jpg]

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.

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.

Quote from 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.

you can either continue ignoring our comments or accept that there are people with something called experience.

why should there be any additional polygons drawn? nodraw still creates leaves. creating non cubic leaves is ALWAYS a pain in the ass.

[Blocked Image: http://kokosovar.free.fr/saemoticonlol.gif]

This is a great optimisation site. All you need to know really. Function detail has the same light properties as world geometry. Basically, if a world brush is not vis blocking or being used to activate a hint brush, turn it into a function detail. That includes whole buildings.

http://www.student.ru.nl/rvanhoorn/opti ... pter=intro

edit - having said that about the light and the function details, this site says this

"There is only a minor bug, which causes light to bounce around a func_detail because the func_detail doesn't break up the world brushes around it (this effect is called lightbleeding, as the light is 'bleeding' around the brushes. Suffice to say that if you didn't understand that, don't worry about it. You will only see it when you make a large brush ( eg wall or floor ) func_detail which blocks light/casts shadows".

I have never experienced it though.

Quote from hessi

you can either continue ignoring our comments or accept that there are people with something called experience.

Yeah, and you can just try to understand what I say.

I'm not contesting your Ô great knowledge, I'm just arguing and making assumptions on things I'm not sure about in order to learn. If talking and contesting is forbidden on this forum, it should have been written somewhere.

Remember something: it's not because people ask questions that they're dumb or that they know nothing about the subject. Thanks.

Quote

This is a great optimisation site.

Yeah thanks, but I already read it a bunch of times. Ralph van Hoorn wrote this tutorial several years ago.. I was using it for HL1.

You can't learn everything from tutorials, sometimes you just need to ask