Poll: Compile Times

3vlNomad

EGO Addict
=(eGO)=
Joined
Sep 30, 2009
Messages
1,326
Okay, I want everyone who has made a "good" map to post their best and worst compile times for that specific map. To be fair, both numbers MUST have been from the "FINAL" compile. If you had it on FAST don't post or else I'll be mad at you :)


ba_jail_oswald_v1
worst: 1wk+ (unoptimized)
best: 53m (fully optimized)
 
Mmm... I guess Ill use ba_jail_devs_v1a3b full compile (HDR enabled[yes I know there's no HDR version on the server, this was used for testing when I got my i7 to see how well of a performance gain I would see with it])

Dual Core system:
Worst: Unoptimized: ~20 minutes
Best: Optimized: 10 minutes

Current i7 system: (This has 8 threads handling compiling vs 2 on the dual core)
Worst: Unoptimized: Someones TF2 map took like 8 minutes with 3000 Visportals
Best: Optimized: 1 minute and 45 seconds

Longest any map takes, optimized or not, cordon tools off or on.
Well executable_a1 takes 45 seconds full compile and HDR.
Every other map maybe like 2 seconds BSP only, 10 seconds w/ fast vvis, 30 seconds BSP & fast vvis/vrad compiles w/o HDR, 1 minute or so full compile with HDR.

Should never take longer than 20 minutes on a dual core system to fully compile a map (this does not take HDR into place however, 30 minutes is the longest compiling should take with HDR checked).
 
Last edited:
I actually cut my visportals down from 27,000 to roughly 7,000 in Oswald. It was taking over a week just for VVIS, got VVIS down to 39m with some mad optimizations. Then VRAD took about 10m, which is probably due to my 385 direct lights and my crazy disco. Large number of visportals is probably caused by the sick semi-circle cell block. All in all it runs extremely smoothly with nominal fps drops in highly detailed areas, which is all that really matters :)
 
6min compile without hdr for undergrowth. Failjail v2 with hdr is something like 4min.

Use one of the batch compiles people have made, no lag and you have more control over the final product.
 
I don't really know any compile times because I don't have the logs and maps with me. But I do agree with Woody that Batch Compilers are much better than the stock one with Hammer.

My favourite compiler: Valve Batch Compile Tool (Homepage)
 
Last edited:
My maps always compile relatively fast, because I properly optimize them. So like anywhere from 2 minutes on Ba_jail_valiant and 10 minutes for pl_hohoho (with it's huge ent_data, huge map, hdr, etc).
 
6min compile without hdr for undergrowth. Failjail v2 with hdr is something like 4min.

Use one of the batch compiles people have made, no lag and you have more control over the final product.

Im about there with Woody. Canyon took about 6 min with HDR. Industrial takes about 3-4 with no HDR

I cant see how it would take hours and hours. Also, thanks for the links for the other compilers. I always just used one in hammer.
 
Typically failure to plan and failure to optimize your map lead to massive compile times. Lack of func_details especially.
 
I learned what happens when you don't have enough func_details the hard way. Too bad I've only seen the sites saying what's bad about func_detail, or maybe I would have known lol.
 
I learned what happens when you don't have enough func_details the hard way. Too bad I've only seen the sites saying what's bad about func_detail, or maybe I would have known lol.

"Not enough" Func details is quite dumb to say. You could have no func details, and it would be optimized fine. Func details just make it so you don't cut up your visleafs with brushes that are fancy designs or something.
 
"Not enough" Func details is quite dumb to say. You could have no func details, and it would be optimized fine. Func details just make it so you don't cut up your visleafs with brushes that are fancy designs or something.

Not entirely correct. Func_detail is used for anything that you see, but does not affect the visiblility of other objects behind it, such as struts, pillars, and supports (usually). If these are not func_detail, the compiler will try to calculate the visibility of all objects around it from every possible angle, resulting in very long compile times like what I had. A func_detail does not split visleafs like a regular object does, and is essentialy "invisible" during the vvis section of the compile. I did not know the benefits of func_detail until a day ago, and therefore my map is not properly optimized.
 
I don't think you understand what I said. When I say "cut up visleafs" I mean things EXACTLY like you pointed out, pillars etc, that cut up visleafs, and don't block visibility.
 

Latest posts

Back
Top