Map compile crashes/hangs on vrad compile

TheCing

L1: Registered
Apr 1, 2015
1
0
Hey all,

Trying to compile my map always results in Hammer crashing once vrad begins its process. There are no errors thrown in the compile log, and viewing the task manager shows vrad.exe using massive amounts of RAM. What do I do about this? Not sure where to go from here.

Thanks in advance,
cing
 

UKCS-Alias

Mann vs Machine... or... Mapper vs Meta?
aa
Sep 8, 2008
1,264
817
Both vvis and vrad can take quite some time in compiles and during the compiles hammer will behave like its not responding. Depending on your hardware and map size, and optimizing the times can vary alot.

Its not rare that a compile will exceed the 10 minute mark. With low optimizing on larger maps this can easily exceed 2 hours.

To actualy check the progress navigate with explorer to the folder where you saved your vmf. there will be a .log file with it. Open that one in a text editor and go the end. it should say something along the lines of:
0...1...2...3...4...5..
This is your progress bar on the compile. Although not a reliable one on that since the 3rd dot after the 9 takes usualy longer than reaching 7. But it gives a general idea of progress.
 

Vel0city

func_fish
aa
Dec 6, 2014
1,947
1,589
Well, it can be caused by a couple of things.

1: You have a lot of very small lightmaps on a lot of surfaces. While it looks pretty, it will also take a lot longer or in semi-rare cases cause the compiler to crash. In the Material Selection menu you have an option to change the lightmap grid size. Default is 16, in areas with higher contrasts between dark spots and lit spots you can go with 8 or 4.

2: Lighting calculations take a lot of time and it often eats up 100% of your CPU time. It's entirely possible for Hammer to become unresponsive during a compile, especially during the VRAD stages. Just let it do its thing. It can take 10 minutes to over 2 hours depending on map size and compiler settings. RAM usage indeed jumps up during VRAD, it needs to store all of its calculated lightmaps in there before it writes them to the bsp file when VRAD's finished.

3: You have a brush or displacement that's made in such a way that VRAD can't figure out for the life of it how it should calculate the lighting for it causing it to hang and eat up your RAM in the process. Look for brushes with weird geometry (they're often invalid as well) or displacements with abnormal geometry like it intersecting itself. I remember when I made a brush about 256x512 HU big, then made a displacement out of it and compressed it down to something like 64x64 with all sorts of up and down geometry on that displacement (I was new to Hammer at that point, I know better now).