vrad.exe error
Centurion
01-04-2006, 08:14 AM
Hey Gents,
Just compiling my dod_merderet Source version and Hammer is crashing when it gets to "FinalLightFace: 0". Tried running map in both normal and expert mode with same result.
As well, just wondering what I should check off in Flags for props_physics_multiplayer so you can't "walk through" props. Right now, they can be moved with the "use" key but they're also non-solids. I've had success making them props_static but I know that's not the correct way to do them ;-)!
Any and all suggestions most welcome thanx!
cheese-sarnie
01-04-2006, 09:00 AM
hi
i possibly had the same thing last week.
mine was caused by func_detail brushes that i had skewed.
i think Furyo spotted it, nice one btw saved me hours :)
more info here (http://developer.valvesoftware.com/wiki/SDK_Beta_Bugs)
(down near the bottom of the page)
Centurion
01-04-2006, 10:41 AM
Hey Cheese,
Many thanks for your quick reply. Unfortunately(?), I don't have any func_details in my map, only func_door_rotating.
Furyo
01-04-2006, 10:51 AM
Centurion, use cordon compiling to locate whatever is causing the problem, and report back what you find (pretty please). It shouldn't take too long to locate the problem.
As of now and as far as I know, this error is known to happen with:
- skewed func_detail brushes
- brushes not aligned to the grid
Centurion
01-04-2006, 10:59 AM
Thanks Furyo,
I'll do that and post reply. The problem just started last night. Prior to this, I'd often get a "level unlit, setting 'mat_fullbright 1' and everything looked washed out. This despite the fact that I'm using light_environment and sky_dod03_hdr as my skybox texture.
Furyo
01-04-2006, 11:54 AM
you should post your whole log, you're likely to have other errors for vrad to tell you you have no lighting
I've had the error happen with standard world brushes, pulled them too far then the side of the brush just basically got deleted, front and back top and bottom were there but the sides were empty and it caused a crash at FinalLightFace.
deleted it after using the Cordon tool and it worked.
ultranew_b
01-04-2006, 03:29 PM
Your not by chance decompiling another map and copy/pasting bsp into the new map are you?
This can lead to problems.
:)
prone ranger
01-04-2006, 04:16 PM
I had this problem with brushes that were either skewed or point edited
if you have any brushes like that, save the map with a different name and delete any likely suspects and try a quick compile (fast vvis and vrad) to see if the error still happens
Ca-Chicken-Soup
01-04-2006, 10:20 PM
Originally posted by Centurion
Hey Cheese,
Many thanks for your quick reply. Unfortunately(?), I don't have any func_details in my map, only func_door_rotating.
Man I'm surprised you got past the visleaf compile with no func_details tinfoil
Sure it's crashing and not just 'not responding'? There's a difference, on is caused by an error (crashing) and the other is it thinking a lot...
try alt + P in the hammer editor to see if there's any buggered brushes or anything else
Furyo
01-05-2006, 05:23 AM
Just a quick note, if it's the usual "func_detail" problem, alt+p won't help as the brush isn't invalid at all.
Centurion
01-05-2006, 07:33 AM
Hello again Gents,
Well, I tried cordoning off my map into 3 separate areas..and all 3 crashed Hammer with the same vrad error as before..lol.
Here are the errors I'm getting now:
1) WARNING: node with unbounded volume
2)make_triangles:calc_triangle_representation: Cannot convert
-0.923360 1.065446 0.000000
-0.923360 -1.064091 0.000000
-0.923360 0.863873 0.000000
-1.142563 1.065446 0.000000
3)GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #1 added RGB(510283, 456004, 281527)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #2 added RGB(92760, 76261, 39543)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #3 added RGB(23740, 18702, 8054)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #4 added RGB(6232, 4505, 1649)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #5 added RGB(1993, 1329, 406)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #6 added RGB(651, 381, 98)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #7 added RGB(237, 122, 26)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #8 added RGB(89, 39, 7)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #9 added RGB(35, 13, 2)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #10 added RGB(14, 5, 1)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #11 added RGB(6, 2, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #12 added RGB(3, 1, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #13 added RGB(1, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #14 added RGB(0, 0, 0)
Build Patch/Sample Hash Table(s).....Done<0.0369 sec>
FinalLightFace: 0...1...2...3...4...5...6...7...8...9...10 (2)
FinalLightFace Done
As you can see, FinalLightFace is working aok..doh!
The unbounded volume error is new (I saved my map files into another folder, deleted and re-setup SDK to see if that helped and thats when this error showed up.
Also, I've compiled this map at least 30 times over the past month and have actually played it on Source. It worked aok. I was trying to correct some of the problems like walking through props before I released it.
I have an earlier copy of my map under a different name..I've read that unbounded volume errors are often difficult to correct(?), so maybe I'm better off re-starting with my older version and correcting it.
Many thanks for all the postings so far!
Furyo
01-05-2006, 08:04 AM
1) I have a similar warning. It doesn't impact anything on dijon so i let it be, especially since it's created by a skybox brush in my case. it's not invalid, but for some reason hammer doesn't like it. Doesn't matter.
2) The problem here is Hammer doesn't know where those errors are. As you have probably noticed, the coordinates are very close to the origin of the map, and you probably don't have brushes there.
The fix is to either use glview and find out where you have bad brush construction, i.e where you see lots of white lines close by; or to use the visgroups filters to only see the world brushes, and try and simplify the design by turning things that shouldn't block vis to func_detail.
This particular error is also known to have appeared with a 2 units wide glass brush (func_breakable) If you've just added glass to your map, check these brushes first and see if making them any different helps.
Also think of never overlapping brushes.
3) no more problem. Are you sure you cordoned off the entire height of the map including the skybox? I don't see how the error could have taken care of itself, but that's the thing with bugs...
If you'd like me to have a look at the vmf, send it to Furyo@907th.com
Day of Defeat Forum Archive created by
Neil Jedrzejewski.
This in an partial archive of the old Day of Defeat forums orignally hosted by
Valve Software LLC.
Material has been archived for the purpose of creating a knowledge base from messages posted between 2003 and 2008.