Having an issue with vrad

Discussion in 'Mapping Questions & Discussion' started by Chromatose, Mar 20, 2013.

  1. Chromatose

    Chromatose L1: Registered

    Messages:
    33
    Positive Ratings:
    0
    So I have this map that I want to run and render in full, but I can never seem to get the lighting stage to work. I have set vrad to run normally but my commands seem to be ignored by the program somehow and I end up with a fullbright map with iffy water. Last night I simply tested to see if the program needed more time to compile or something silly like that by leaving it to run for 14 hours and the results were no different. Here is my log:

    Code:
    ** Executing...
    ** Command: "c:\program files (x86)\steam\steamapps\highwaytohell666acdc\sourcesdk\bin\orangebox\bin\vbsp.exe"
    ** Parameters: -game "c:\program files (x86)\steam\steamapps\highwaytohell666acdc\team fortress 2\tf" "C:\Program Files (x86)\Steam\SteamApps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1.vmf"
    
    Valve Software - vbsp.exe (Oct 31 2012)
    4 threads
    materialPath: c:\program files (x86)\steam\steamapps\highwaytohell666acdc\team fortress 2\tf\materials
    Loading C:\Program Files (x86)\Steam\SteamApps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1.vmf
    Can't find surfaceprop stone for material EGYPT/HYRO_BORDER_BUMP_NEW, using default
    ConVarRef mat_reduceparticles doesn't point to an existing ConVar
    Can't find surfaceprop mudslipperyslime for material CUSTOM/MCLAVA, using default
    fixing up env_cubemap materials on brush sides...
    Material CUSTOM/MCWATER is depending on itself through materialvar $bottommaterial! Ignoring...
    Material CUSTOM/MCLAVA is depending on itself through materialvar $bottommaterial! Ignoring...
    ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (0)
    ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (1)
    Processing areas...done (0)
    Building Faces...done (0)
    FixTjuncs...
    PruneNodes...
    WriteBSP...
    Can't find surfaceprop mudslipperyslime for material maps/trade_plaza_mops_comp_4_1/custom/mclava_depth_68, using default
    Can't find surfaceprop mudslipperyslime for material maps/trade_plaza_mops_comp_4_1/custom/mclava_depth_57, using default
    Can't find surfaceprop mudslipperyslime for material maps/trade_plaza_mops_comp_4_1/custom/mclava_depth_4, using default
    done (0)
    writing C:\Program Files (x86)\Steam\SteamApps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1.prt...Building visibility clusters...
    done (0)
    Can't find surfaceprop mudslipperyslime for material maps/trade_plaza_mops_comp_4_1/custom/mclava_depth_2, using default
    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 (3) (254516 bytes)
    Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
    Compacting texture/material tables...
    Reduced 1128 texinfos to 765
    Reduced 102 texdatas to 83 (3255 bytes to 2465)
    Writing C:\Program Files (x86)\Steam\SteamApps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1.bsp
    8 seconds elapsed
    
    ** Executing...
    ** Command: "c:\program files (x86)\steam\steamapps\highwaytohell666acdc\sourcesdk\bin\orangebox\bin\vvis.exe"
    ** Parameters: -game "c:\program files (x86)\steam\steamapps\highwaytohell666acdc\team fortress 2\tf" "C:\Program Files (x86)\Steam\SteamApps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1"
    
    Valve Software - vvis.exe (Oct 31 2012)
    4 threads
    reading c:\program files (x86)\steam\steamapps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1.bsp
    reading c:\program files (x86)\steam\steamapps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1.prt
    1604 portalclusters
    5268 numportals
    BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (3)
    PortalFlow:          0...1...2...3...4...5...6...7...8...9...
    ** Executing...
    ** Command: "c:\program files (x86)\steam\steamapps\highwaytohell666acdc\sourcesdk\bin\orangebox\bin\vrad.exe"
    ** Parameters: -both -game "c:\program files (x86)\steam\steamapps\highwaytohell666acdc\team fortress 2\tf" "C:\Program Files (x86)\Steam\SteamApps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1"
    
    SteamStartup() failed: SteamStartup(0xf,0x0031EE40) failed with error 1: The registry is in use by another process, timeout expired
    
    
    ** Executing...
    ** Command: Copy File
    ** Parameters: "C:\Program Files (x86)\Steam\SteamApps\highwaytohell666acdc\sourcesdk_content\tf\mapsrc\trade_plaza_mops_comp_4_1.bsp" "c:\program files (x86)\steam\steamapps\highwaytohell666acdc\team fortress 2\tf\maps\trade_plaza_mops_comp_4_1.bsp"
    
    
    ** Executing...
    ** Command: c:\program files (x86)\steam\steam.exe
    ** Parameters: -applaunch 440 -game "c:\program files (x86)\steam\steamapps\highwaytohell666acdc\team fortress 2\tf" -toconsole -dev -console +sv_lan 1 +map "trade_plaza_mops_comp_4_1"
    So I analysed this log on interlopers.net and was told the following;
    "Note: It appears vrad was not included in this compile log.
    Not running vrad may cause various errors, make sure you run all compile tools if you are stuck on an unnamed error."


    Any ideas how I would go about solving this? Thanks guys.
     
  2. nightwatch

    aa nightwatch

    Messages:
    640
    Positive Ratings:
    446
    To me it looks like the vvis process was killed before completion. I could be wrong though. What do you mean by saying that "perhaps it needed more time to compile"? Do you ever end the process, assuming it is finished? Because if you let it go by itself it will always take the same amount of time, unless you use different compile options or the .vmf is changed.
     
  3. Chromatose

    Chromatose L1: Registered

    Messages:
    33
    Positive Ratings:
    0
    On this occasion I ended it prematurely because of the insane compile time that has came with my map update. I assumed it wasn't doing a whole lot. The log window and hammer froze shortly after running the map so I could not monitor its progress making the render come down to guess work.
     
  4. Chromatose

    Chromatose L1: Registered

    Messages:
    33
    Positive Ratings:
    0
    So with the above said, does anyone have any ideas?
     
  5. nightwatch

    aa nightwatch

    Messages:
    640
    Positive Ratings:
    446
    If it was indeed the vvis process that didn't complete, I can only suggest that you optimize for visleaf compilation. Can you do the following so we can help you better?

    -Start a server with the last version of your map that DID compile.
    -go to every area in the map THAT NOW CONTAINS SOMETHING NEW in the version that DOESN'T compile and take a screenshot.
    - Then Enter into console:
    ---sv_cheats 1
    ---mat_leafvis 3
    - And take new screenshots of each area.
    Then open hammer and take a few screenshots of your Work In Progress (of the same areas) so we can see what it is that you're adding that is hurting compile time so much.

    Good luck!
     
  6. colacan

    colacan L5: Dapper Member

    Messages:
    235
    Positive Ratings:
    66
    Killing ANY of the compile processes is a bad idea, because that normally leads to having to restart steam for it to work again. vvis was killed, and that's the issue, not vrad.
    To make vvis not hang (too much):
    Make sure that you have func_detailed anything that is round, a pillar, a round pillar, a small overhang or not blocking visibility in a significant way. If you don't, vvis can go insane with compile times.
     
  7. henke37

    aa henke37

    Messages:
    1,832
    Positive Ratings:
    420
    And you can significantly speed up vvis by using func_viscluster. Just remember that everything it touches must be visible by everything else it touches.
     
  8. ics

    aa ics http://ics-base.net

    Messages:
    654
    Positive Ratings:
    410
    If your vvis takes long time to compile, you might have a design issue in your map. Something like block bullets brushes twisted in odd angles or oddly shaped brush that causes a lot of vis calculations.

    Map -> load portal file will show you where the problem may be.
     
  9. Dïcecübe

    Dïcecübe L3: Member

    Messages:
    114
    Positive Ratings:
    31
    If you got brushes/blocks with "block bullets" textures on. Select it -> CRTL + T -> Profit!
    It should make it to a "func_detail". Which don't CUT any VIS-leaves.
    If you got much brushes that serve as detail to the enviorment, you should func_detail them too.
     
  10. Chromatose

    Chromatose L1: Registered

    Messages:
    33
    Positive Ratings:
    0
    Sure thing! Here are the screens as requested:

    http://imgur.com/YlLNGz0
    http://imgur.com/7qWUwFm
    http://imgur.com/qbUn3g0
    http://imgur.com/kkVhfuI
    http://imgur.com/EIPJ2Yr
    http://imgur.com/xgFmdY5
     
  11. Chromatose

    Chromatose L1: Registered

    Messages:
    33
    Positive Ratings:
    0
    I had no choice but to kill it unfortunately. I left it on for quite some time to compile, the log window immediately stopped responding so I couldn't watch the compliers progress, and it seems after a good few hours, vvis was no longer contributing to the cpu usage, but the process was not switching to vrad which is really strange (and annoying) making progress impossible unless I killed the process.
     
  12. Crash

    aa Crash func_nerd

    Messages:
    3,068
    Positive Ratings:
    4,555
    Based on the pictures, your map needs to be optimized badly.

    I would highly recommend reading this page thoroughly, especially the parts about func_details.

    All your stairs and extra detail objects should be func_detailed. This is why vvis is taking so long.
     
  13. Crash

    aa Crash func_nerd

    Messages:
    3,068
    Positive Ratings:
    4,555
    I recommend not using this entity unless you fully know what you're doing with it. You can do more harm than good if you aren't solid on the concepts behind it.
     
    • Thanks Thanks x 1
  14. henke37

    aa henke37

    Messages:
    1,832
    Positive Ratings:
    420
    Indeed, using it incorrectly is only going to lead to pain.
     
  15. Chromatose

    Chromatose L1: Registered

    Messages:
    33
    Positive Ratings:
    0
    Your advice solved the issue! Have a thanks! (I owe you a hat)
     
  16. Crash

    aa Crash func_nerd

    Messages:
    3,068
    Positive Ratings:
    4,555