got any suggestion on how to make the normal compile be faster?

Billo

aa
Feb 8, 2016
920
397
Well, i have my map pl_cliffedge which i am working hard on it and i want it to turn out to be one of the best payload maps out there obviously.But I have a problem which the normal compile (all on normal mode)
takes a lot of hours more that 9. My friend told me that may be a case of poor optimization or func_details or something like that but i am not sure exactly what it is.
 

corpsgrinder360

L1: Registered
Jan 30, 2016
29
6
if you have tons of brushes, that will make the compile slower. try and optimize your map and if you see more polygons than are required for a brush get rid of them.
 
Mar 23, 2013
1,013
347
if you have tons of brushes, that will make the compile slower. try and optimize your map and if you see more polygons than are required for a brush get rid of them.

Turning brushes into less complex ones probably only speeds up VBSP which is the fastest part to compile anyway (abound 2-15 seconds depending on complexity/hardware)

What's taking 9 hours to compile is VVIS. go to map>load area portals to view the visleafs in your level and when they are unecessarily complex or tiny due to small brushes that aren't func_detail, then turn those brushes into func_detail so your visleafs don't take shapes that give the compiler a hard time.

Also, even if you properly use func_detail, vvis also can have trouble compiling very huge open spaces. if you have something like that, (like a really huge open space ala HL2 coast levels) then use func_viscluster for this area of the map.
 

MOCOLONI

L6: Sharp Member
Dec 16, 2014
373
89
Just like suggested above, doing a proper func_detail workaround should decrease the compiling time. Note that when it comes to testing minor changes or so, you could always set "VIS" (and "RAD", if you wish to) compile modes to "Fast", but also rememeber not to use it on "final" map versions. Switch back to "Normal" when the map is ready to get released.
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
VVIS is usually the cause of unreasonably long compile times. When you compile your map, VBSP splits up space into visleaves, and VVIS compares which visleaves can see each other. If a lot of visleaves can see each other, then it takes longer to complete its job. By reducing the number of visleaves (by converting insignificant world brushes into func_detail or replacing them with props) you can cut down VVIS time, but you can also reduce the chance for leaves to see each other by using buildings, cliffs and corridors to isolate areas and obscure sightlines.

In order to make effective design and vis-opt decisions, you really need to understand how visleaves are created and how visibility between them is calculated. There are a number of guides available to introduce you to the vis-opt toolset. It's going to take some time to understand it, so don't worry if it seems like a lot of work.

Some example guides:
Touching on what Lampenpam said, if you want to see how VBSP will make its visleaves, you do a VBSP-only compile (no VVIS, VRAD or anything else), then load the default portal file (Map > Load Portal FIle). Study the blue boxes, looking for clusters of small ones, and see how many can see each other between large areas. Don't worry about visleaves that look messy and don't treat func_detail as a magic bullet. You should only be using it on very small brushes like steps and posts.
 

killohurtz

Distinction in Applied Carving
aa
Feb 22, 2014
1,016
1,277
It's important to note that func_viscluster should NOT be used as a band-aid solution for bad optimization. Yes, it will reduce compile times, but like func_detail, it won't do anything to help performance. If the map still runs poorly, you'll need to use actual performance optimization tools like hint, areaportals, and occluders (as described in the guides linked above).