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

Discussion in 'Mapping Questions & Discussion' started by basilhs333, Jun 22, 2017.

  1. basilhs333

    basilhs333 L8: Fancy Shmancy Member

    Messages:
    575
    Positive Ratings:
    146
    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.
     
  2. corpsgrinder360

    corpsgrinder360 L1: Registered

    Messages:
    24
    Positive Ratings:
    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.
     
    • Respectfully Disagree Respectfully Disagree x 1
  3. basilhs333

    basilhs333 L8: Fancy Shmancy Member

    Messages:
    575
    Positive Ratings:
    146
    so i need to have less area portals?
     
  4. Crash

    aa Crash func_nerd

    Messages:
    3,149
    Positive Ratings:
    4,750
    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.
     
    • Thanks Thanks x 1
    • Like Like x 1
  5. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    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.
     
  6. MOCOLONI

    MOCOLONI L5: Dapper Member

    Messages:
    243
    Positive Ratings:
    60
    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.
     
  7. worMatty

    aa worMatty Repacking Evangelist

    Messages:
    1,072
    Positive Ratings:
    834
    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.
     
  8. Crash

    aa Crash func_nerd

    Messages:
    3,149
    Positive Ratings:
    4,750
    This page is pretty good for your specific issue, but the whole thing is a great read.
     
    • Thanks Thanks x 1
  9. snowsquirrel

    snowsquirrel L3: Member

    Messages:
    135
    Positive Ratings:
    22
  10. killohurtz

    aa killohurtz Distinction in Applied Carving

    Messages:
    1,003
    Positive Ratings:
    1,155
    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).
     
    • Agree Agree x 2