13+ Hour Long Compile?

Discussion in 'Mapping Questions & Discussion' started by Nicknam4, Jul 4, 2012.

  1. Nicknam4

    Nicknam4 L1: Registered

    Messages:
    28
    Positive Ratings:
    8
    Hey guys. Virtually finished making my map here, and since I wanted this final test to be put on my server for some friends to play with, I set vrad and vvis to normal instead of fast. Bad idea. It's been compiling all night and still going at just over 13 hours. I'm sure this is because of stupid mistakes I made on my part (Like making a square skybox...) however they were things I never worried too much about because I didn't realize it would take this long. Fast settings took not even 10 minutes.

    My computer is still running really slow so I think it's still running and not simply frozen. The map isn't very big but I do have maybe 50-100 props. How long should I continue waiting for it to compile, and are compiles lasting longer than 4-5 hours that common?

    Thanks guys.
     
  2. xzzy

    aa xzzy

    Messages:
    815
    Positive Ratings:
    393
    A "fast" vis compile should take less than a minute. A normal vis run will generally be under 20 minutes.

    If it takes more than an hour, you need to fix your map.
     
  3. Wander

    Wander L3: Member

    Messages:
    148
    Positive Ratings:
    42
    • Thanks Thanks x 1
  4. phi

    aa phi Within The Vacuum Of Infinity...

    Messages:
    795
    Positive Ratings:
    1,519
    Take a look at Valve's maps and you'll see that practically EVERYTHING that doesn't impede sight is a func_detail. Trims, ramps, roofs, anything that sticks out and anything oddly angled should be a func_detail. Others could explain it better but that's what I do to get 9 minute compiles in near-beta.
     
  5. bob+M|M+

    bob+M|M+ L6: Sharp Member

    Messages:
    348
    Positive Ratings:
    185
    Occasionally hammer DOES just freeze and there's no way of really knowing. That's why you should use the vbct compiler instead. It will never freeze, it doesn't lock up your computer so you can use the internet while you compile, and you will see the continuous progress bar. It's great! Although the major problem here is probably your optimization. Also if fast settings take you 10 minutes, normal shouldn't be more than ~30 minutes.
     
    • Thanks Thanks x 1
    Last edited: Jul 4, 2012
  6. Nicknam4

    Nicknam4 L1: Registered

    Messages:
    28
    Positive Ratings:
    8
    Thanks a bunch everyone! I didn't know about func_detail so that should help tremendously with the map's optimization. Also, thanks for that vbct compiler, had no idea it existed. That will make a huge difference to knowing how close to finished it is. ;)

    I've ran into a few problems with props, though. When I make a prop that the player can't come in contact with, I make it a prop_detail, but while I playtest, every prop_detail shows the ERROR model. Anyone know what causes this?
     
  7. bob+M|M+

    bob+M|M+ L6: Sharp Member

    Messages:
    348
    Positive Ratings:
    185
    I've never used prop_detail, but prop_static is usually the way to go. Prop_static with collisions turned off.

    yeah for func_detail, you'll be wanting to func_detail the majority of your map, anything that is not a perfect block. So stairs, slants, slopes, cylindrical shapes, etc. A quick way to do this is fly around in your 3D view by holding space+left click+aswd to move around, click on objects, hold ctrl+click for multiple select, and then ctrl+T to instantly change it to func_detail. But just keep in mind func_details don't plug leaks.
     
    • Thanks Thanks x 1
  8. Ravidge

    aa Ravidge Grand Vizier

    Messages:
    1,544
    Positive Ratings:
    2,495
    prop_detail is not something you place manually, it's a special type of prop that is used by textures, to place bushes and branches randomly on the ground.
    It's more or less completely defunct in TF2.

    For TF2 you want to use prop_static in the VAST majority of cases. prop_dynamic has a few uses, but you'll learn where and when with time.
     
    • Thanks Thanks x 1
  9. RaVaGe

    aa RaVaGe

    Messages:
    728
    Positive Ratings:
    1,054
    Uh, stop saying bullshit, if your vvis take more than 2 minutes, it's over, in general, my vvis is during less than 10 seconds, even if it's a payload.
     
    • Thanks Thanks x 1
  10. LeSwordfish

    aa LeSwordfish semi-trained quasi-professional

    Messages:
    4,109
    Positive Ratings:
    6,059
    VVis varies depending on your computer, but 20 mins seems reasonable to me. Later versions of Atoll were taking 15-20 mins for vvis, so it's hardly bullshit to suggest 2 mins is too much.
     
  11. grazr

    aa grazr Old Man Mutant Ninja Turtle

    Messages:
    5,436
    Positive Ratings:
    3,564
    You can compile a payload map with normal vvis in 10 seconds? What the fuck?

    ---

    You should never compile in fast mode unless your intention is to debug entity logic. fastvis is not a shortcut to determine whether your map compiles or not. Always make sure your map compiles normally. The longer you leave your map the more issues and more complicated and irreversable errors become, and the harder they are to discover the source of.

    For future reference it is recommended you don't fast compile at all. In fact i'd only suggest using it if you're a novice as it is a tool, not a means to an end.

    In all likely hood your map simply takes so long because it is open and with limited manual optimisation; and you've exaserbated the issue by not optimising as you go, having relied on fast compiles. So the issue isn't really a bug, it's just your map. But it would help if you A) give us your computer specs and B) show us a picture of your map so we can determine whether its a system performance issue, poor map design, a combination of them both or something else.
     
    Last edited: Jul 4, 2012
  12. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,033
    Positive Ratings:
    3,980
    That's not necessarily true; look at how Viaduct is optimized, or Gravelpit.

    Also I can make any map compile in 20 seconds too. The trick is to just func_detail every bit of world geometry so you're just compiling an empty cube. Still get shit optimization.
     
  13. henke37

    aa henke37

    Messages:
    1,890
    Positive Ratings:
    443
    A good trick to speed up vvis is to use func_viscluster.
     
  14. RaVaGe

    aa RaVaGe

    Messages:
    728
    Positive Ratings:
    1,054
    Yep pl_decay was compiling in less than 10 seconds, but it was only optimised with area_portal, i guess if i had some stranges hints in the map the vvis time would take a little longer, like 1-2 minutes, but it's a big drama for me if vvis take more than 2 min.
     
  15. Nicknam4

    Nicknam4 L1: Registered

    Messages:
    28
    Positive Ratings:
    8
    Here is what the map looks like, it is pretty simple. (Blu is the same, but mirrored)
    [​IMG]

    You can probably see why it took so long immediately. None of those brushes are func_details. Silly mistake on my part.
     
  16. phi

    aa phi Within The Vacuum Of Infinity...

    Messages:
    795
    Positive Ratings:
    1,519
    Also you probably want skybox brushes instead of those huge nodraw walls
     
  17. Nicknam4

    Nicknam4 L1: Registered

    Messages:
    28
    Positive Ratings:
    8
    Yes but if I do that, you can't see the border behind them, at least I thought.

    Also, should I make the floors func_details as well since there isn't anything below the map?
     
  18. RaVaGe

    aa RaVaGe

    Messages:
    728
    Positive Ratings:
    1,054
    Please take a look at valve's map, uncheck the toolbrush, the func_detail and the props, in the visgroups and look how it's made.
     
  19. Ravidge

    aa Ravidge Grand Vizier

    Messages:
    1,544
    Positive Ratings:
    2,495
    What is this fight about "my vvis takes X minutes, so there!"... completely meaningless.
    vvis depends on your CPU, the size of the map, and how the map is structured, you can't just say "It should take 5 minutes!" neither can you say "it should take 10 seconds!".

    first of all: func_detail doesn't optimize the map. It only optimizes vvis.

    Having a faster than usual vis pass generally just means your vvis didn't find much to calculate, in other words there is not much actual map optimization going on. What you did instead was optimize your compile times.
    Having a slower than usual vis means vvis is calculating a lot of stupid things that it wouldn't need to if you kept your func_detailing in order.

    Comparing times (between people, and computers) is stupid unless you're both/all using the same benchmark vmf when timing yourselves.


    ---

    Nicknam4: your problem is the nodraw cones inside the trees, I suggest changing the texture to "blockbullets" and make them func_detail as well. The reason being that it will have the same effect as nodraw does now, but blockbullets won't create large black shadows.

    The slanted rooftops are also a issue, but compared to the tree-cones its minimal.
     
    • Thanks Thanks x 1
  20. Nicknam4

    Nicknam4 L1: Registered

    Messages:
    28
    Positive Ratings:
    8
    Yes, after doing research about Vvis I facepalmed about the tree cones. Never knew about the blockbullets texture though, I will give that a try. Thanks.