13+ Hour Long Compile?

Nicknam4 · Jul 4, 2012

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.

xzzy · Jul 4, 2012

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.

Wander · Jul 4, 2012

Have a look at this guide: http://www.optimization.interlopers.net
It sounds like especially the func_detail chapter might help you

phi · Jul 4, 2012

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.

bob+M|M+ · Jul 4, 2012

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.

Nicknam4 · Jul 4, 2012

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?

bob+M|M+ · Jul 4, 2012

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.

Ravidge · Jul 4, 2012

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.

RaVaGe · Jul 4, 2012

xzzy said:
A normal vis run will generally be under 20 minutes.

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

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.

LeSwordfish · Jul 4, 2012

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.

grazr · Jul 4, 2012

RaVaGe said:
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.

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.

tyler · Jul 4, 2012

PDT said:
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.

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.

henke37 · Jul 4, 2012

A good trick to speed up vvis is to use func_viscluster.

RaVaGe · Jul 4, 2012

grazr said:
You can compile a payload map with normal vvis in 10 seconds? What the fuck?

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.

Nicknam4 · Jul 4, 2012

grazr said:
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.

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.

Here is what the map looks like, it is pretty simple. (Blu is the same, but mirrored)

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

phi · Jul 4, 2012

Also you probably want skybox brushes instead of those huge nodraw walls

Nicknam4 · Jul 4, 2012

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?

RaVaGe · Jul 4, 2012

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.

Ravidge · Jul 4, 2012

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.

Nicknam4 · Jul 4, 2012

Ravidge said:
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.

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.

Search

Search

13+ Hour Long Compile?

Nicknam4

L1: Registered

xzzy

Wander

L3: Member

phi

bob+M|M+

L6: Sharp Member

Nicknam4

L1: Registered

bob+M|M+

L6: Sharp Member

Ravidge

Grand Vizier

RaVaGe

LeSwordfish

semi-trained quasi-professional

grazr

Old Man Mutant Ninja Turtle

tyler

henke37

RaVaGe

Nicknam4

L1: Registered

phi

Nicknam4

L1: Registered

RaVaGe

Ravidge

Grand Vizier

Nicknam4

L1: Registered

If this is your first time logging in after the migration (Feb 8, 2022), you must reset your password to log in. Follow this guide if you're having trouble