Vvis.exe long compile, how can I fix it?

What do I need to do to fix or shortin the vvis.exe Or what is the proper way of using hint brushes

By Resol 3 years ago

I am wanting to track down the cause or what might cause the compile time for a map to be insanlly long as in 18+ hours and still not finished.

Fast Facts:

  • Large brushed (hollowed cube) all around the map
  • 30 or so props (as in trees,rocks)
  • compile options all set to normal
  • vvis.exe after like 15+hours is still grinding away(btw the compiling takes 99% of my cpu load)
  • 3.0Ghz duo core, 2g RAM
  • What do I need to do to help prevent long vvis compiles?
  • And would the hint brushes fix this and how to use them properlly?

Long info/Back Story

It happened once on a map I was messing with but only when I did the full compile. It seems the issue is when the vvis.exe is run and from what I know of on what the program does is it carves the map up into visual blocks to help with runtime renderings of the map and what brushes to draw when and such. Now when this first happend I didnt care about making the map look fancy and such so I just did the cheap compile on it but the map I am working on now I want to look good and play good (the other map I heard ALOT of ppl complain it laged lol)

So below is a youtube I made for a friend and was gonna show it to here to let it be the discription of the map so far.(video was take with fraps from the hammer editer) http://www.youtube.com/watch?v=kChke0gjv0Q

But the reason I am posting this is to find out what I need to look at to help this map to compile. I know of the hint brush I think its called but am not really sure the proper way of using it in this map since I REALLY want the map to be open. Like the 2 areas I have now I want it so if ppl want to the can try and throw nades into the other area. BUT I dont know how to go about spliting the map up so the comiler knows what to be drawing when. In other words how do I tell the compiler that when ur in the frist area dont bother drawing the 2nd area until you see into the arch way leading to it. (I am assuming since the skybox texture and the accual walkable map area are so far apart the vvis.exe is running even when you are below the map) I am plaing on later going thour and moving the sky box brushes in more but right now I was just waiting. So this long compule might simply be from that but figured i would still ask incase theres something im not looking at or thinking of myself.

Thanks :)

Sorry for the long post but I really want to find more info on how to both fix this map and prevent it in later maps.

9 posts 1,122 views

Replies

    • P1: Beggar
      Points: 172
    • C1: Member
    • A4: Graduate
      Account Age: 4 years

    You might have too many brushs,but post your compile log

    Banned
    • P1: Beggar
      Points: 201
    • C1: Member
    • A5: Veteran
      Account Age: 4 years

    First off thanks for the youtube embed in reply and When i go to bed I will start the compule again. When i get up I will end the hammer prosses and copy paste that info in a reply here.

    Oh and the first area compiled fine with normal compile options (but that was before i removed the skybox brushes and make a new cube (hollowed) and started on the 2nd area)

    Im here, Your there, Live with
    • P1: Beggar
      Points: 201
    • C1: Member
    • A5: Veteran
      Account Age: 4 years

    Ok I was doing more searching and found this... http://www.fpsbanana.com/tuts/5149

    Which as im reading is making me really think its these vis leafs that are being created via the vvis.exe due to the open map and the large skybox lol

    But will still post the compile log incase theres other crap im doing wrong or missing lol

    Im here, Your there, Live with
    • P1: Beggar
      Points: 626
    • E1: Helper
      EF: 5
    • C1: Member
    • A4: Graduate
      Account Age: 3 years

    This is what I know. Compile times can be long, a few hours if you have lots of small very intricate brushes. From what I saw of your map this is not the case. Large areas can be cut up very quickly because they are big empty areas and it doesn't take a lot of thought to make a big empty box.

    How Hint brushes work. vvis.exe is a smart program and will 90% of the time do a fine job. If you have something fairly complicated vvis might make up its own answer that is not the most optimal. Adding a brush that has one side textured with the tools/hint texture will tell the compiler to automatically cut one of its invisible box lines along that texture.

    If you want to see wthis process. In game run your map or any map really. In console type in 'svcheats 1' and then type in 'matleafvis 1' you should notice that you are standing inside of a red box. This red box is that invisible box that vvis created. As you move around you will see how you move from block to block. Typing 'mat_wireframe 1' will show you all of the objects that your computer is processing. If you then see the wireframes of a bunch of stuff that isn’t in your line of sight or immediately visible within a few seconds walk, then you would want to optimize compiling with hint brushes closing off those the areas between you and those models.

    All this is good to know but I don’t think it has anything to do with your problem. Vvis and the compiler in Hammer is notorious for crashing and failing. After you hit that okay button in the Run map dialog box you can’t click on anything. ANYTHING! If you click on the compile process window, outside of the compile process window, or on anything at all you will most likely cause vvis.exe to crash and fail and continue to take up 99% of your CPU while it does absolutely nothing. Just ctrl+alt+dlt and end the vvis.exe process.

    The solution? I really wouldn’t use the compiler in Hammer if you have something that won’t compile inside of a few minutes because it completely consumes your computer. Most mappers for real maps use a Batch Compiler. Nem has an awesome one free for download here. Nem's Batch Compiler

    It might take a while to set up and learn to use but it won’t crash or lock up your computer and it runs in the background so you can do other things while the map is compiling.

    Hope all this helped. :|

    • P1: Beggar
      Points: 201
    • C1: Member
    • A5: Veteran
      Account Age: 4 years
    Posted by Hypnophobiac This is what I know. .......Hope all this helped. :|

    Yes thanks and I think i see what you mean about the crashes but I know on the last map i had this issue on i left it over night got up it was still going. I made a note as to the point it was at, that line with '...4....5' well it was at like '2..' after i went to work (that was like 5 hours or so from the time i got up and back from work. It did change but it was at 3 so I dont know if the the log just adds the dots at random points but if it did crash (as in not computing) i dont think it would respond ever.

    But will still look into the info and the batch compuler :) BTW I was trying to figure out how ppl were seing there vis leafs lol. Now i just need to get this map to compile so i can see mine lol

    Im here, Your there, Live with
    • P2: Drudge
      Points: 5,576
    • E2: Guide
      EF: 24
    • C1: Member
    • A5: Veteran
      Account Age: 5 years
    Posted by Hypnophobiac Here's how vvis.exe works. It is a program that runs once while you are compiling. It slices your map up into invisible little blocks. When the game engine is running it automatically interprets these blocks. The game already knows if I'm here I'm in this box. This box can see the box next to it and that other box over there. I need to render the textures and models in these 3 boxes but nothing else anywhere else because I can’t see that.

    This is actualy already done in the processblock steps of vbsp. And hints are also done in that processblock step in vbsp. This is why you usualy find leaks in that step, as it simply notices that a leaf from inside the map touches the void. Vvis however uses that info to check which box can see which. And by some heavy calculating it will check which blocks can be seen from where. And this is what will optimize the map as any block you dont see wont be rendered.

    But as the map is fairly simple in its construction but has alot of detailed edges i suspect those of being the couse. 10+ hours in such pc is just too long to say its optimized (i dont even have half of that pc hardware and rarely had a compile of 3+ hours - and when i did i know why it was that long).

    The solution most likely is to be done with funcdetail brushes. Any detailed corner should be made out of them and it will massively improve the compile time. And especialy the spiral stairs can be a pain for compile times if they arent funcdetailed.

    The reason a vvis takes long is by the ammount of leaves you have. If you have 100 leaves it only has to check the visibility from 100 leaves to 100 leaves (say 10000 steps - its actualy less as the tool is a bit smarter). compare that to 500 leaves, normaly you expect it to take about 5 times as long (which normaly is true if the map is built well) but it can actualy be 25 times (500x500=250000). And this many times happens to increase massively if you messed up some brushwork or didnt func_detail a few parts. (carve is known to couse such artifacts so if you used that then it could be the main couse even more likely then the stairs)

    The box arround the map does increase compile times but many times the impact of them is minor (they however should not be used for final compiles as they still do have a negative impact).

    Using a custom tool might help in improving the compile times but then still... If it doesnt compile fast in hammer its usualy a sign you did something wrong for optimizing anyway.

    Also, if you see vvis being at 5.. and later it says 3.. then its most likely means vvis was done and went on with vrad instead.

    The Knifosaurus
    • P5: Peddler
      Points: 156,185
    • E6: Authority
      EF: 219
    • C4: Super Moderator
    • A6: Elder
      Account Age: 6 years
    Logan Dougall

    Giant Box around your map is a big culprit there, this will help explain why:

    .awesome { Uberstylers:Club; }
    • P1: Beggar
      Points: 201
    • C1: Member
    • A5: Veteran
      Account Age: 4 years

    Ok I agree with Lost and UKCS (I was REALLY tired last night but I do remember seeing in the hammer docs that vvis didnt calculate the leafs it only decided what ones could see each other) But I did shrink the skybix brushes to alot the sides of the map. Still after I went to bed and got up It was still going. I ended hammers prosses and and the log file is post at end of this post.

    Even thou I was really tired I was correct in thinking I need to optimize the vis leafs I think i understand the elements i need to so I can fix this issue (might take a bit but I think i see how to do it now lol)

    Right now (lost from your link) some of that info for my map is this lol 5210 portalclusters 16150 numportals

    So ya I need to fix/optimize the vis leafs and i think since the way i have my map i will need to make each are completly enclosed with the skybox brushes except for the paths connecting them.

    Heres the file(i ended the hammer prosses after about 6 hours or so after i got up)

    materialPath: c:\program files\steam\steamapps[steam login]\counter-strike source\cstrike\materials Loading C:\Program Files\Steam\steamapps[steam login]\sourcesdkcontent\cstrike\mapsrc\bunkers.vmf Can't find surfaceprop iron for material MODELS/PROPSDEBRIS/REBARMEDTHIN02, using default fixing up envcubemap materials on brush sides... 0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Processing areas...done (0) Building Faces...done (1) FixTjuncs... PruneNodes... WriteBSP... done (1) writing C:\Program Files\Steam\steamapps[steam login]\sourcesdkcontent\cstrike\mapsrc\bunkers.prt...done (2) Creating default cubemaps for envcubemap using skybox materials: skybox/skyday0109*.vmt Run buildcubemaps in the engine to get the correct cube maps.

    No such variable "$hdrbasetexture" for material "skybox/skyday0109rt" Can't load skybox file skybox/skyday0109 to build the default cubemap! Finding displacement neighbors... Finding lightmap sample positions... Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10 Building Physics collision data... done (2) (632680 bytes) Placing detail props : 0...1...2...3...4...5...6...7...8...9...10 Compacting texture/material tables... Reduced 2389 texinfos to 1641 Reduced 21 texdatas to 19 (488 bytes to 445) Writing C:\Program Files\Steam\steamapps[steam login]\sourcesdk_content\cstrike\mapsrc\bunkers.bsp 32 seconds elapsed

    2 threads reading c:\program files\steam\steamapps[steam login]\sourcesdkcontent\cstrike\mapsrc\bunkers.bsp reading c:\program files\steam\steamapps[steam login]\sourcesdkcontent\cstrike\mapsrc\bunkers.prt 5210 portalclusters 16150 numportals 0...1...2...3...4...5...6...7...8...9...100...

    [Reading texlights from 'lights.rad'] [1 texlights parsed from 'lights.rad']

    Loading c:\program files\steam\steamapps[steam login]\sourcesdk_content\cstrike\mapsrc\bunkers.bsp No vis information, direct lighting only. 13863 faces 80 degenerate faces 4433828 square feet [638471360.00 square inches] 41 displacements 85787 square feet [12353332.00 square inches] 2 direct lights 0...1

    Im here, Your there, Live with
    • P1: Beggar
      Points: 201
    • C1: Member
    • A5: Veteran
      Account Age: 4 years

    Ok I wanted to thank you all for giving the info you gave. After a few hours of changing some brushes to func_detail and moving the skyboxes in I got the portals down from... 5210 portalclusters 16150 numportals

    to..

    571 portalclusters 1797 numportals

    So now I have a map i JUST compiled in under 30mins so thats an ok amount to for me compaired to well i dont know how long the other would have taken lol

    Thanks agian

    Im here, Your there, Live with