Welcome to PlagueFest.com! Log in or Sign up to interact with the Plague Fest community.
  1. Welcome Guest! to interact with the community and gain access to all the site's features.

Compile Time

Discussion in Mapping Discussion started by sajak, Jun 21, 2012

  1. Nov 11, 2011
    I've finished working on version 2 of zm_breakout. I've reduced the size of the map exponentially as well as increased the overall lighting. The issue is that everytime I run a compile in Normal mode, it takes over 45 minutes. My CPU usage never goes above 17% (which is abnormal).

    On my first version of breakout, which was much, much larger, a full hdr compile -final would take less than 10 minutes to compile. CPU usage would hit 100% (which is normal).

    Some quick facts: Everything is snapped to the grid (except for displacements :doh: ), areaportals and func_details implemented (same as first version, nothing changed), no leaks. Here is the compile log. Notice the bold text and the numportals and portalclusters, they are within the norm for my maps. Version 1 had 553 portalclusters and 1404 numportals and took 9 seconds elapsed. I also removed all entities and lighting and only left world brushes and compiled, it took nearly the same amount of time. CPU usage didn't go above 17% either... the affinity is set to use all six cores and priority is set to High.


    ** Executing...
    ** Command: "c:\program files (x86)\steam\steamapps\_scx_\sourcesdk\bin\orangebox\bin\vbsp.exe"
    ** Parameters: -game "C:\program files (x86)\steam\steamapps\_scx_\counter-strike source\cstrike" "C:\Users\scx\Desktop\vmf\zm_breakout_v2f.vmf"

    Valve Software - vbsp.exe (Apr 26 2012)
    6 threads
    materialPath: C:\program files (x86)\steam\steamapps\_scx_\counter-strike source\cstrike\materials
    Loading C:\Users\scx\Desktop\vmf\zm_breakout_v2f.vmf
    ConVarRef mat_reduceparticles doesn't point to an existing ConVar
    Could not locate 'GameData' key in c:\program files (x86)\steam\steamapps\_scx_\counter-strike source\cstrike\gameinfo.txt
    Patching WVT material: maps/zm_breakout_v2f/nature/blendsandweed005a_wvt_patch
    fixing up env_cubemap materials on brush sides...
    ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (0)
    ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (0)
    Processing areas...done (0)
    Building Faces...done (0)
    Chop Details...done (0)
    Find Visible Detail Sides...
    Merged 526 detail faces...done (0)
    Merging details...done (0)
    done (0)
    writing C:\Users\scx\Desktop\vmf\zm_breakout_v2f.prt...Building visibility clusters...
    done (0)
    Creating default LDR cubemaps for env_cubemap using skybox materials:
    ! Run buildcubemaps in the engine to get the correct cube maps.
    Creating default HDR cubemaps for env_cubemap using skybox materials:
    ! Run buildcubemaps in the engine to get the correct cube maps.
    Finding displacement neighbors...
    Found a displacement edge abutting multiple other edges.
    Warning: overflowed 16 displacement corner-neighbor lists.Finding lightmap sample positions...
    Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
    Building Physics collision data...
    done (0) (533585 bytes)
    Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
    Compacting texture/material tables...
    Reduced 2308 texinfos to 1166
    Reduced 312 texdatas to 258 (15311 bytes to 13101)
    Writing C:\Users\scx\Desktop\vmf\zm_breakout_v2f.bsp
    4 seconds elapsed

    ** Executing...
    ** Command: "c:\program files (x86)\steam\steamapps\_scx_\sourcesdk\bin\orangebox\bin\vvis.exe"
    ** Parameters: -game "C:\program files (x86)\steam\steamapps\_scx_\counter-strike source\cstrike" "C:\Users\scx\Desktop\vmf\zm_breakout_v2f"

    Valve Software - vvis.exe (Apr 26 2012)
    6 threads
    reading c:\users\sxc\desktop\vmf\zm_breakout_v2f.bsp
    reading c:\users\sxc\desktop\vmf\zm_breakout_v2f.prt
    482 portalclusters
    1269 numportals
    BasePortalVis: 0...1...2...3...4...5...6...7...8...9...10 (0)
    PortalFlow: 0...1...2...3...4...5...6...7...8...9...10 (2709)
    Optimized: 106 visible clusters (0.12%)
    Total clusters visible: 89502
    Average clusters visible: 185
    Building PAS...
    Average clusters audible: 411
    visdatasize:55077 compressed from 61696
    writing c:\users\scx\desktop\vmf\zm_breakout_v2f.bsp
    45 minutes, 9 seconds elapsed

    ** Executing...
    ** Command: "c:\program files (x86)\steam\steamapps\_scx_\sourcesdk\bin\orangebox\bin\vrad.exe"
    ** Parameters: -game "C:\program files (x86)\steam\steamapps\_scx_\counter-strike source\cstrike" "C:\Users\scx\Desktop\vmf\zm_breakout_v2f"

    Valve Software - vrad.exe SSE (Apr 26 2012)

    Valve Radiosity Simulator
    6 threads
    [Reading texlights from 'lights.rad']
    [2 texlights parsed from 'lights.rad']

    Loading c:\users\scx\desktop\vmf\zm_breakout_v2f.bsp
    Error! Unable to load file "models/props_interiors/magazine_rack.dx80.vtx"
    Error! Unable to load file "models/props_plants/plantairport01.dx80.vtx"
    Error! Unable to load file "models/props_unique/hospital/surgery_lamp.dx80.vtx"
    Error! Unable to load file "models/props_vehicles/train_ladder.dx80.vtx"
    Setting up ray-trace acceleration structure... Done (3.47 seconds)
    5174 faces
    1 degenerate faces
    629288 square feet [90617520.00 square inches]
    324 Displacements
    848 Square Feet [122173.42 Square Inches]
    5173 patches before subdivision
    64321 patches after subdivision
    sun extent from map=0.139173
    369 direct lights
    BuildFacelights: 0...1...2...3...4...5...6...7...8...9...10 (47)
    BuildVisLeafs: 0...1...2...3...4...5...6...7...8...9...10 (15)
    transfers 13317603, max 1241
    transfer lists: 101.6 megs
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Bounce #1 added RGB(112081, 110410, 111544)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
    Bounce #2 added RGB(18744, 16649, 15190)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Bounce #3 added RGB(4916, 3555, 2688)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
    Bounce #4 added RGB(1592, 869, 518)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Bounce #5 added RGB(591, 234, 110)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Bounce #6 added RGB(247, 69, 25)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
    Bounce #7 added RGB(110, 22, 6)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Bounce #8 added RGB(51, 7, 2)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
    Bounce #9 added RGB(24, 3, 0)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Bounce #10 added RGB(12, 1, 0)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
    Bounce #11 added RGB(6, 0, 0)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Bounce #12 added RGB(3, 0, 0)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Bounce #13 added RGB(1, 0, 0)
    GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
    Bounce #14 added RGB(1, 0, 0)
    Build Patch/Sample Hash Table(s).....Done<0.0259 sec>
    FinalLightFace: 0...1...2...3...4...5...6...7...8...9...10 (8)
    FinalLightFace Done
    0 of 0 (0% of) surface lights went in leaf ambient cubes.
    ThreadComputeLeafAmbient: 0...1...2...3...4...5...6...7...8...9...10 (6)
    Writing leaf ambient...done
    Ready to Finish

    Object names Objects/Maxobjs Memory / Maxmem Fullness
    ------------ --------------- --------------- --------
    models 90/1024 4320/49152 ( 8.8%)
    brushes 1582/8192 18984/98304 (19.3%)
    brushsides 11593/65536 92744/524288 (17.7%)
    planes 8382/65536 167640/1310720 (12.8%)
    vertexes 8946/65536 107352/786432 (13.7%)
    nodes 1574/65536 50368/2097152 ( 2.4%)
    texinfos 1166/12288 83952/884736 ( 9.5%)
    texdata 258/2048 8256/65536 (12.6%)
    dispinfos 324/0 57024/0 ( 0.0%)
    disp_verts 8100/0 162000/0 ( 0.0%)
    disp_tris 10368/0 20736/0 ( 0.0%)
    disp_lmsamples 12672/0 12672/0 ( 0.0%)
    faces 5174/65536 289744/3670016 ( 7.9%)
    hdr faces 0/65536 0/3670016 ( 0.0%)
    origfaces 3983/65536 223048/3670016 ( 6.1%)
    leaves 1665/65536 53280/2097152 ( 2.5%)
    leaffaces 6119/65536 12238/131072 ( 9.3%)
    leafbrushes 2666/65536 5332/131072 ( 4.1%)
    areas 40/256 320/2048 (15.6%)
    surfedges 40536/512000 162144/2048000 ( 7.9%)
    edges 25485/256000 101940/1024000 (10.0%)
    LDR worldlights 369/8192 32472/720896 ( 4.5%)
    HDR worldlights 0/8192 0/720896 ( 0.0%)
    leafwaterdata 0/32768 0/393216 ( 0.0%)
    waterstrips 484/32768 4840/327680 ( 1.5%)
    waterverts 0/65536 0/786432 ( 0.0%)
    waterindices 8829/65536 17658/131072 (13.5%)
    cubemapsamples 59/1024 944/16384 ( 5.8%)
    overlays 3/512 1056/180224 ( 0.6%)
    LDR lightdata [variable] 2387920/0 ( 0.0%)
    HDR lightdata [variable] 0/0 ( 0.0%)
    visdata [variable] 55077/16777216 ( 0.3%)
    entdata [variable] 350483/393216 (89.1%) VERY FULL!
    LDR ambient table 1665/65536 6660/262144 ( 2.5%)
    HDR ambient table 1665/65536 6660/262144 ( 2.5%)
    LDR leaf ambient 5691/65536 159348/1835008 ( 8.7%)
    HDR leaf ambient 1665/65536 46620/1835008 ( 2.5%)
    occluders 0/0 0/0 ( 0.0%)
    occluder polygons 0/0 0/0 ( 0.0%)
    occluder vert ind 0/0 0/0 ( 0.0%)
    detail props [variable] 1/12 ( 8.3%)
    static props [variable] 1/53836 ( 0.0%)
    pakfile [variable] 4988961/0 ( 0.0%)
    physics [variable] 533585/4194304 (12.7%)
    physics terrain [variable] 38818/1048576 ( 3.7%)

    Level flags = 0

    Total triangle count: 14251
    Writing c:\users\scx\desktop\vmf\zm_breakout_v2f.bsp
    1 minute, 27 seconds elapsed

    ** Executing...
    ** Command: Copy File
    ** Parameters: "C:\Users\scx\Desktop\vmf\zm_breakout_v2f.bsp" "c:\program files (x86)\steam\steamapps\scx\counter-strike source\cstrike\maps\zm_breakout_v2f.bsp"
    sajak, Jun 21, 2012 Last edited by sajak, Jun 21, 2012
  2. Apr 9, 2012
    First make sure you didn't accidentically textured the world brushes beneath displacements with the skybox texture. Not that this has anything to do with the compile time but it adds a drooly amount of lighting clusters nevertheless...

    There is only 1 thing I can think of for a solution, as it has been implemented after Episode One:

    This has been created to prevent any compiling to take a unusual amount of time to be processed. Put these around everywhere in your map.
    Couple of things you need to know about this:
    - They are not entities, so don't worry about that
    - They won't eat planes for if that might be a problem
    - They do not exist in the map after the compile as they are removed afterwards.
    - They can NEVER cross the surface of a water brush. Instead make one right above it and right underneath it. However imo you only should make one above it.
    - They should NOT cross any world brush, however func_details may be safely ignored
    - They do not change any visibility, they just make the compile going MUCH faster

    There you go

    EDIT: Before attempting, for all security reasons you should save your map under another name with a _test prefix or anything that fits you, because otherwise if it still didn't work you won't have to bear with removing them all again. It's just a tip

    EDIT 2: Ow yea, to make it really clear in case you were wondering: It does not change your optimization at all! It won't change any FPS whereever you'll put them, so don't worry about an exaggerating use of them!
    • Zing! Zing! x 1
      JorisCeoen, Jun 21, 2012 Last edited by JorisCeoen, Jun 21, 2012
    • Nov 11, 2011
      After adding one huge viscluster in the open area of my map, it resulted in a huge difference 273 portalclusters and 445 numportals. It took 1 minute, 31 seconds elapsed to compile in normal (43 minutes less). For the most part, everything works well. I'll update if I see any issues. Thanks a lot Joris! :victory:
    • Apr 9, 2012
      Haha! Glad to see it's been solved :smile:
      • Winner Winner x 1
      • Nov 11, 2011
        I have this sign on the right hand side, the whole thing is a func_detail. On the left hand side is my func_viscluster trigger.

        After compiling, everything in the map works except the sign comes up as a black shadow:


        As you can see, the sign doesn't show up. The trigger isn't touching the func_detail either. It's odd because the building next to it on the same wall is also a func_detail but isn't affected. Any ideas?
      • Jul 4, 2011
        Try making the viscluster meet the wall.
      • Nov 11, 2011
        I thought they can't touch world brushes?
      • Jul 4, 2011
        func_detail is not a world brush, it doesn't cut visleaves. I suggest turning all visgroups off but world geometry when making visclusters. I'm not entierly sure though regarding visclusters and world brushes, I've had a few overlap world brushes before and they still do their job.
      • Nov 11, 2011
        Duh. I meant the wall that has the sign and the building attached to it. It is a world brush which also has three edges which are sealing the map.


        EDIT: Tried everything... doesn't work with that player clip. Removed it and it works fine. GAHHH! Oh well.
        sajak, Jun 21, 2012 Last edited by sajak, Jun 21, 2012
      • Mar 26, 2009
        Haha, you're horribly misinformed and wrong.

        func_viscluster is not a magic entity that fixes all problems with a map. func_viscluster tells vvis.exe that all visleaves generated by vbsp.exe can all see each other and to not bother with visibility calculations between all visleaves contained within the func_viscluster. func_viscluster can make compile times go faster, but it will also drastically affect the PVS of players rendering the map. Carelessly making huge func_visclusters in random places without regard to how things are being chopped into visleaves with cause horrible performance problems and severely reduce client frame rates.

        If you cover an entire map in a single func_viscluster, congratulations, you just made the entire map basically into one visleaf. Everything in the map will be rendered at all times and either make the map unplayable, or make frame rates so bad that the map isn't worth even looking at.
      • Nov 11, 2011
        I would have to agree that what you just said, makes sense. But the outside of my map is an open space where you can pretty much see everything there is to see outside. So it won't hurt to add a viscluster outside simply to reduce vvis compile time.

        But I DON'T agree with this explanation: [IMG]
        • Funny Funny x 1
        • Apr 9, 2012
          Have you actually tried looking INTO the map to see if visleaves have been changed?
          For the record, "Carelessly making huge func_visclusters in random places without regard to how things are being chopped into visleaves with cause horrible performance problems and severely reduce client frame rates.

          If you cover an entire map in a single func_viscluster, congratulations, you just made the entire map basically into one visleaf. Everything in the map will be rendered at all times and either make the map unplayable, or make frame rates so bad that the map isn't worth even looking at."

          While I agree it's not like Sajak did this, he carefully placed one in the correct place and it solved his problem for 99%
          I feel like you're wanting to say that this is a useless entity no matter what. I don't think I misinformed him.
          The least, he at least doesn't have to wait 43 for a far more horrible reason that would have otherwise also been able to provide horrific performance.
          • Like Like x 1
          • Mar 26, 2009
            As I've already said, func_viscluster doesn't change visleaves, it tells vvis.exe that all visleaves inside the func_viscluster can all see each other and no visibility calculations are done on them. This is what saves compile time.

            It's a useless entity to people like yourself that have no idea how to use it properly. You're telling people to "put it everywhere in their map":

            Then you go on to explain wrongly how it works:

            1) func_viscluster IS an entity.
            2) It counts as a brush entity, so it uses space even though it doesn't count towards the final entity count.
            3) Like hint and skip brushes, the compile tools never use the func_viscluster brush as part of the compile solution.
            4) Worldspawn water can't have a func_viscluster cross into it, but func_water_analog cheap water can.
            5) If it can't cross worldspawn, then you couldn't have concave areas with func_viscluster (which isn't true, you can have world brushes inside func_viscluster.)
            6) They completely change visibility, what crackpipe are you smoking. Client PVS is based on visleaves, and using a func_viscluster on a group of visleaves means that any client standing within that group will automatically see every other visleaf in the group (ie. huge potential for FPS impact.)

            Why do something useless like this when you can just use the entity search tool to find all instances of func_viscluster to delete them?

            Again, you have no idea what you're talking about. Stop giving terrible mapping advice.
          • Apr 9, 2012
            The thing is that I gave mapping advice and since you thought it was a useless entity you would have never mentioned anything and thus been unable to solve his problem in the first place.
            At least his problem is solved right now and thanks to your extra information over my misinformation it's all very clear to him. I only didn't really liked the way you (seem) to hate onto me by simply answering all my arguments as if I had only give him more problems without having anything solved.

            It's solved and I'm sure he's really happy even though the most I said was wrong.
            Completely solving his problem by misinformation is better than not solving his problem at all by giving proper information :-/
            I hope everyone is happy now :smile:
            • Agree Agree x 2
            • JorisCeoen
              This message by JorisCeoen has been removed from public view. Deleted by JorisCeoen, Jun 22, 2012.
              Jun 22, 2012
            • May 15, 2011

              Spoken like a gentleman.
            • Nov 11, 2011
              The problem here is that Joris gave the correct advice but he just had some facts wrong. It ultimately helped my compile problems and we all learned a thing or two. I just found it rude the way gigabite went about stating the correct facts, quite arrogantly in fact. He is correct though, it is a brush entity and all func_viscluster tells vvis is that all the visleafs in that particular trigger, can see each other. So if you incorrectly place them, you will have severe FPS issues even though compile time will be incredibly quick. In a sense, you're doing vvis's job.

              Joris, I recommend you keep helping out people when they need it, and if you end up being wrong, it may still be helpful (just like in this case). Thanks for your advice and thanks for keeping it professional. :thumbsup:
              • Like Like x 1
              • Winner Winner x 1
              • May 15, 2011
                So, if you were to place a bunch of these throughout your map, having one for each corridor and blah blah blah, you're basically doing .VVIS inside Hammer, without compiling? If so, that would be very helpful for not only compile times, but ensuring certain aspects of the map are rendered/ optimized in the way YOU want it to be or would it be best to stay with just hints/skips? I know Gig explained but it was filled with such rage I couldn't really get anything out of it except hate. Letters and words full of hot, steamy hate. :3
              • Nov 11, 2011
                Well, technically you're supposed to only use them in larger spaces around world geometry where you are sure that you can see that area within that trigger. You don't need one visleaf asking another if it can see it, if it can see the next, the next one, the next one, and so and so forth. The func_viscluster tells vvis that all the leafs in that trigger can see each other and to move on to the next area. There is really no point in using them in doors with regular spaces because it doesn't take that long for vvis to compute visleafs. I was learning about the portal file from gigabite yesterday but he had to leave. I'll ask him to explain here how that works.
                • Like Like x 1
                • Nov 2, 2011
                  Just dont map like sajak and you will not need func_viscluster. Problem solve.
                  • Like Like x 1
                  • Wizard! Wizard! x 1
                  • Nov 11, 2011
                    LOL I love you Jermaine :heart: