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

Discussion in 'Mapping Questions & Discussion' started by Kiester Felterbutts, Jul 15, 2008.

  1. Kiester Felterbutts

    Kiester Felterbutts L1: Registered

    Messages:
    7
    Positive Ratings:
    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.
     
  2. AKAfreaky

    AKAfreaky L1: Registered

    Messages:
    7
    Positive Ratings:
    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.
     
  3. Kiester Felterbutts

    Kiester Felterbutts L1: Registered

    Messages:
    7
    Positive Ratings:
    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:
     
  4. YM

    aa YM LVL100 YM

    Messages:
    7,099
    Positive Ratings:
    5,741
    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 -
    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)
     
  5. Rehsa4

    Rehsa4 L1: Registered

    Messages:
    35
    Positive Ratings:
    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
     
  6. Kiester Felterbutts

    Kiester Felterbutts L1: Registered

    Messages:
    7
    Positive Ratings:
    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.
     
  7. YM

    aa YM LVL100 YM

    Messages:
    7,099
    Positive Ratings:
    5,741
    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.
     
  8. Jacfu

    Jacfu L1: Registered

    Messages:
    10
    Positive Ratings:
    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 )
     
  9. Kiester Felterbutts

    Kiester Felterbutts L1: Registered

    Messages:
    7
    Positive Ratings:
    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.