Having an issue with vrad

Chromatose

L1: Registered
May 10, 2012
33
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.
 
Sep 7, 2012
638
500
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.
 

Chromatose

L1: Registered
May 10, 2012
33
0
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.

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.
 
Sep 7, 2012
638
500
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!
 

colacan

L5: Dapper Member
Apr 14, 2012
235
85
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.
 

henke37

aa
Sep 23, 2011
2,075
515
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.
 

ics

http://ics-base.net
aa
Jun 17, 2010
841
541
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.
 

Arne

L3: Member
Nov 22, 2012
114
55
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.
 

Chromatose

L1: Registered
May 10, 2012
33
0
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!

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
 

Chromatose

L1: Registered
May 10, 2012
33
0
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.

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.
 

Crash

func_nerd
aa
Mar 1, 2010
3,316
5,499
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.
 

Crash

func_nerd
aa
Mar 1, 2010
3,316
5,499
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.

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.
 

henke37

aa
Sep 23, 2011
2,075
515
Indeed, using it incorrectly is only going to lead to pain.
 

Chromatose

L1: Registered
May 10, 2012
33
0
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.

Your advice solved the issue! Have a thanks! (I owe you a hat)