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

[Billo]

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]

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.

 

[Billo]

so i need to have less area portals?

 

[Crash]

You probably have a ton of small brushes that aren't func detailed. Any brush that doesn't block visibility or seals the map should probably be detailed.

Areaportals are fine.

 

[Lampenpam]

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]

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]

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:

• http://www.nodraw.net/2009/12/optimization-in-source-a-practical-demonstration/
  
• View: https://www.youtube.com/watch?v=swBfUW-Bsxs
  
  
• https://developer.valvesoftware.com/wiki/Visibility_optimization

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.

 

[Crash]

This page is pretty good for your specific issue, but the whole thing is a great read.

 

[squ1rrel]

func_viscluster(s) are useful for vvis compile times... Top Hatt Waffle explains it well.

View: https://www.youtube.com/watch?v=Ds5E7HBQ-nU

 

[killohurtz]

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