"vrad.exe has stopped responding...Windows will now close the program"

Kiester Felterbutts

L1: Registered
Dec 10, 2007
7
0
I get this error when trying to compile a pretty large map. Here is the log file from my latest attempt

materialPath: c:\program files (x86)\steam\steamapps\xxxx\team fortress 2\tf\materials
Loading E:\Steam_Crap\Steam_Maps\Team Fortress vmfs\pl_h2h_x_07.vmf
Patching WVT material: maps/pl_h2h_x_07/concrete/blendconcdirt004a_wvt_patch
Patching WVT material: maps/pl_h2h_x_07/ground/grass2mud_wvt_patch
fixing up env_cubemap 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 (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 980 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (2)
writing E:\Steam_Crap\Steam_Maps\Team Fortress vmfs\pl_h2h_x_07.prt...Building visibility clusters...
done (0)
Creating default LDR cubemaps for env_cubemap using skybox materials:
skybox/sky_hydro_01*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Creating default HDR cubemaps for env_cubemap using skybox materials:
skybox/sky_hydro_01*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
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 (4) (1379685 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 2705 texinfos to 1392
Reduced 84 texdatas to 67 (2089 bytes to 1466)
Writing E:\Steam_Crap\Steam_Maps\Team Fortress vmfs\pl_h2h_x_07.bsp
21 seconds elapsed



4 threads
reading e:\steam_crap\steam_maps\team fortress vmfs\pl_h2h_x_07.bsp
reading e:\steam_crap\steam_maps\team fortress vmfs\pl_h2h_x_07.prt
3044 portalclusters
9105 numportals
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Optimized: 9165 visible clusters (0.00%)
Total clusters visible: 1206363
Average clusters visible: 396
Building PAS...
Average clusters audible: 994
visdatasize:855929 compressed from 2337792
writing e:\steam_crap\steam_maps\team fortress vmfs\pl_h2h_x_07.bsp
1 hour, 10 minutes, 27 seconds elapsed



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

Loading e:\steam_crap\steam_maps\team fortress vmfs\pl_h2h_x_07.bsp
24567 faces
20 degenerate faces
7795642 square feet [1122572544.00 square inches]
403 Displacements
944202 Square Feet [135965168.00 Square Inches]
24547 patches before subdivision
zero area child patch
606049 patches after subdivision
237 direct lights
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...

Basically it gets anywhere between 6 and 9 on the vrad step and stops. One thing I did notice is that in Task Manager vrad.exe is using up around 1.5 GB or RAM when it stops responding. I've changed a lot trying to figure this problem out, but keep coming to the same problem.

I've run into many problems before compiling maps, but this one has me stumped as I've never seen vrad use up that much memory.

Oh, and I'm running Vista 64-bit with 4GB of RAM.

Thanks in advance for any help.
 

AKAfreaky

L1: Registered
May 4, 2008
7
2
Description:
A solid in your level has a face with no area. My guess is that vrad.exe is trying to create a lightmap for a face that doesn't exist. Maybe you have an invalid brush?

Solution:
First check Hammers problemchecker (alt+p). If that doesn't solve your problems, you can either ignore the error, or try to find it anyway using cordon tools. You would be looking for brushes which might be too complex. I wouldn't recommend the second option.

Taken from the Interlopers.net compile log check.
 

Kiester Felterbutts

L1: Registered
Dec 10, 2007
7
0
Already checked there and that error has been there for a while. It isn't causing my problem with the vrad compile, or at least not directly related anyway since it's been there since the early stages of this one.

Thanks anyway. :unsure:
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
20 degenerate faces!?!?! what the hell are you doing to that poor map!!?!?! (those are faces with no area and should NOT happen unless you're being rubbish with the vertex tool)

Look how long VVIS takes -
1 hour, 10 minutes, 27 seconds elapsed
THAT is the problem, poor VRAD is working its arse off because you've fed it an unbelievably messy map, its no wonder its stopped.

Do you know what a func_detail is? if not FIND OUT!!!
Then make sure all your geometry that isn't func_detailed is nicely on the grid (16, 32 or 64 if possible but 8 or 4 is ok if you must)
 

Rehsa4

L1: Registered
Mar 7, 2008
35
3
yeah... the

1 hour, 10 minutes, 27 seconds elapsed

is a big issue. No matter how big a map is, I think 30 minutes maximum for a full compile is about right from what i've heard if you've done your map correctly. Heck, a full compile of my WIP map takes about 4 minutes total, expecting it to take more later, but it is usually done with the vvis within 2 minutes if not 1 minute as it is the vrad and lighting that takes the longest time.

Youme has a good link, but it doesn't explain much as to WHY you use a func_detail.

to find out why to use a func detail etc, please follow the below link, you will be quite happy you did.

http://www.student.ru.nl/rvanhoorn/optimization.php?chapter=func_detail
 

Kiester Felterbutts

L1: Registered
Dec 10, 2007
7
0
I know what func_detail is and how to use it. Yes there are quite a bit of complex geometry areas but I've had maps take 2 hours on vvis and have no problem at all with vrad.

Mainly what I was looking for is if anyone else has ever had a similar issue with vrad freezing up like that. Thanks for your input thus far and I will try to check out those links to see if anything jumps out at me.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Its not exactly a case of how long it takes, its how complex all the visleaves are, so your 1 hour one might make loads more horrible visleaves than the 2hour one, causing rad to lock up.

Regardless of if vvis is causing your problem you reallly need to cut down that vis time, its not doing your map any good, framerates are probably way lower than they could be.
 

Jacfu

L1: Registered
May 27, 2008
10
1
Hope you get it sorted Kiester.
Vrad always takes the longest to compile for me, vvis usually goes rather fast ( depending on map size ) , but I think 1 hour for vvis is going to create some problems.

When I started mapping about a year and a half ago I made this huge hl2dm map that took 24 + hours to compile vvis ( no func_details - I didnt know about it then )
Vrad would go to about 8 ... 9 and just sit there for hours until I terminate the process.
( task manager would say that vrad has stopped responding when in fact it was still running )
 

Kiester Felterbutts

L1: Registered
Dec 10, 2007
7
0
I appreciate all of the input thus far. I know I'll need to optimize it quite a bit, but I was hoping it was something simple as lighting is always my biggest issue.

Thanks again.