Wesley Tack Posted December 12, 2006 Report Posted December 12, 2006 Hello, We have had this problem for quite some time now, for some reason our weapons are always dark when walking on the level you spawn, but when you look up the weapon gets brighter. Or if not looking up and I jump on an object the weapon also lights up. Anyone have any idea's ? It's the same with or without specular maps. Cheers
hessi Posted December 12, 2006 Report Posted December 12, 2006 i know this effect from hl1 and all valve games. its not a bug you can actually fix. it has nothing to deal with your model oder shading. it seems to depend on the level. some places tend to give the player view a crappy TNL light setup, so your view gets brighter or darker for a moment. i wont care about that unless its not in absolutly fullbright areas where your model gets dark. maybe you are walking on a func_detail? in old hl1 days this effect appead when walking over the void. for example you had some stairs as a func_wall and under the func_wall there was nothing then the skybox or the null texture.maybe you can look in this direction to _fix_ it.
Wesley Tack Posted December 12, 2006 Author Report Posted December 12, 2006 well, underneath that street (which is func_detail) there is another brush (the main layout) but underneath that there is a void yes. If thats what you mean. If this is indeed the problem, then I don't really know how to fix that, or I would have to loose a lot of func_details, which would only be bad for the performance. I'll do some tests anyway, see if this is indeed the case. Thanks for the swift reply!
Campaignjunkie Posted December 12, 2006 Report Posted December 12, 2006 I think the func_detail is blocking light from reaching the brush underneath - so when it samples the lightmap under the player's feet to light the weapon model, it chooses the dark world brush that's covered in shadow rather than the func_detail. My advice: Turn the street back to a world brush. Why would you func_detail it anyway?
hessi Posted December 12, 2006 Report Posted December 12, 2006 I think the func_detail is blocking light from reaching the brush underneath - so when it samples the lightmap under the player's feet to light the weapon model, it chooses the dark world brush that's covered in shadow rather than the func_detail. My advice: Turn the street back to a world brush. Why would you func_detail it anyway? that was what i tried to recommend with my post
Zacker Posted December 13, 2006 Report Posted December 13, 2006 I am very curious about what kind of good reason you would have for making the floor func_detail.
Wesley Tack Posted December 13, 2006 Author Report Posted December 13, 2006 Thanks for all the replies! I made the sidewalks/street func_detail cause I thought it would help the performance, anyways, I compiled the map again last night, and this time beneath my feet there are no func_details anymore, sidewalks/streets are all simple brushes now. But still the weapons are so dark. Could this have anything to do with the hight of my map? Even though I placed my light_environment straight down...? What causes the 1st person weapons to light up anyway? I think the light_environment? Just to be on the safe side I'll also post my LOG, maybe you can see something in it that would explain things more? materialPath: c:\program files\valve\steam\steamapps\SourceMods\OffLimits\materials Loading C:\Program Files\Valve\Steam\SteamApps\SourceMods\OffLimits\maps\ol_styx.vmf 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 (1) Find Visible Detail Sides... Merged 2672 detail faces...done (2) Merging details...done (1) FixTjuncs... PruneNodes... WriteBSP... done (2) writing C:\Program Files\Valve\Steam\SteamApps\SourceMods\OffLimits\maps\ol_styx.prt...done (0) Creating default cubemaps for env_cubemap using skybox materials: skybox/de_cobble_hdr*.vmt Run buildcubemaps in the engine to get the correct cube maps. Creating default HDR cubemaps for env_cubemap using skybox materials: skybox/de_cobble_hdr*.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 (1) (1295790 bytes) Placing detail props : 0...1...2...3...4...5...6...7...8...9...10 Compacting texture/material tables... Reduced 3915 texinfos to 2404 Reduced 497 texdatas to 436 (21361 bytes to 19199) Writing C:\Program Files\Valve\Steam\SteamApps\SourceMods\OffLimits\maps\ol_styx.bsp 25 seconds elapsed 1 threads reading c:\program files\valve\steam\steamapps\sourcemods\offlimits\maps\ol_styx.bsp reading c:\program files\valve\steam\steamapps\sourcemods\offlimits\maps\ol_styx.prt 766 portalclusters 1356 numportals 0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Optimized: 86 visible clusters (0.00%) Total clusters visible: 38340 Average clusters visible: 50 Building PAS... Average clusters audible: 151 visdatasize:65923 compressed from 147072 writing c:\program files\valve\steam\steamapps\sourcemods\offlimits\maps\ol_styx.bsp 4 seconds elapsed [Reading texlights from 'lights.rad'] [46 texlights parsed from 'lights.rad'] Loading c:\program files\valve\steam\steamapps\sourcemods\offlimits\maps\ol_styx.bsp 11559 faces 4 degenerate faces 1929582 square feet [277859840.00 square inches] 25 displacements 64295 square feet [9258601.00 square inches] 11555 patches before subdivision 242161 patches after subdivision 346 direct lights 0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10transfers 21039146, max 763 transfer lists: 160.5 megs 0...1...2...3...4...5...6...7...8...9...10 Bounce #1 added RGB(476159, 394235, 215807) 0...1...2...3...4...5...6...7...8...9...10 Bounce #2 added RGB(79085, 62099, 28859) 0...1...2...3...4...5...6...7...8...9...10 Bounce #3 added RGB(15652, 11540, 4505) 0...1...2...3...4...5...6...7...8...9...10 Bounce #4 added RGB(3314, 2313, 772) 0...1...2...3...4...5...6...7...8...9...10 Bounce #5 added RGB(764, 504, 144) 0...1...2...3...4...5...6...7...8...9...10 Bounce #6 added RGB(182, 114, 29) 0...1...2...3...4...5...6...7...8...9...10 Bounce #7 added RGB(45, 27, 6) 0...1...2...3...4...5...6...7...8...9...10 Bounce #8 added RGB(11, 6, 1) 0...1...2...3...4...5...6...7...8...9...10 Bounce #9 added RGB(3, 2, 0) 0...1...2...3...4...5...6...7...8...9...10 Bounce #10 added RGB(1, 0, 0) Build Patch/Sample Hash Table(s).....Done<0.3012 sec> 0...1...2...3...4...5...6...7...8...9...10FinalLightFace Done 0 of 0 (0% of) surface lights went in leaf ambient cubes. ComputePerLeafAmbientLighting: 0...1...2...3...4...5...6...7...8...9...10 Ready to Finish Object names Objects/Maxobjs Memory / Maxmem Fullness ------------ --------------- --------------- -------- models 17/1024 816/49152 ( 1.7%) brushes 3880/8192 46560/98304 (47.4%) brushsides 27609/65536 220872/524288 (42.1%) planes 13044/65536 260880/1310720 (19.9%) vertexes 23980/65536 287760/786432 (36.6%) nodes 2411/65536 77152/2097152 ( 3.7%) texinfos 2404/12288 173088/884736 (19.6%) texdata 436/2048 13952/65536 (21.3%) dispinfos 25/0 4400/0 ( 0.0%) disp_verts 1969/0 39380/0 ( 0.0%) disp_tris 3104/0 6208/0 ( 0.0%) disp_lmsamples 150380/0 150380/0 ( 0.0%) faces 11559/65536 647304/3670016 (17.6%) hdr faces 0/65536 0/3670016 ( 0.0%) origfaces 8315/65536 465640/3670016 (12.7%) leaves 2429/65536 77728/2097152 ( 3.7%) leaffaces 15509/65536 31018/131072 (23.7%) leafbrushes 7950/65536 15900/131072 (12.1%) areas 4/256 32/2048 ( 1.6%) surfedges 92005/512000 368020/2048000 (18.0%) edges 61028/256000 244112/1024000 (23.8%) LDR worldlights 345/8192 30360/720896 ( 4.2%) HDR worldlights 0/8192 0/720896 ( 0.0%) waterstrips 2062/32768 20620/327680 ( 6.3%) waterverts 0/65536 0/786432 ( 0.0%) waterindices 37176/65536 74352/131072 (56.7%) cubemapsamples 319/1024 5104/16384 (31.2%) overlays 55/512 19360/180224 (10.7%) LDR lightdata [variable] 7506712/0 ( 0.0%) HDR lightdata [variable] 0/0 ( 0.0%) visdata [variable] 65923/16777216 ( 0.4%) entdata [variable] 261093/393216 (66.4%) LDR leaf ambient 2429/65536 58296/1572864 ( 3.7%) HDR leaf ambient 0/65536 0/1572864 ( 0.0%) occluders 8/0 320/0 ( 0.0%) occluder polygons 48/0 576/0 ( 0.0%) occluder vert ind 208/0 832/0 ( 0.0%) detail props [variable] 1/12 ( 8.3%) static props [variable] 1/89920 ( 0.0%) pakfile [variable] 27847578/0 ( 0.0%) Level flags = 0 Win32 Specific Data: physics [variable] 1295790/4194304 (30.9%) ==== Total Win32 BSP file data space used: 40318120 bytes ==== Total triangle count: 35590 Writing c:\program files\valve\steam\steamapps\sourcemods\offlimits\maps\ol_styx.bsp 1 hour, 14 minutes, 19 seconds elapsed [Reading texlights from 'lights.rad'] [46 texlights parsed from 'lights.rad'] Loading c:\program files\valve\steam\steamapps\sourcemods\offlimits\maps\ol_styx.bsp 11559 faces 4 degenerate faces 1929582 square feet [277859840.00 square inches] 25 displacements 64295 square feet [9258601.00 square inches] 11555 patches before subdivision 242161 patches after subdivision 346 direct lights 0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10transfers 21039146, max 763 transfer lists: 160.5 megs 0...1...2...3...4...5...6...7...8...9...10 Bounce #1 added RGB(476159, 394235, 215807) 0...1...2...3...4...5...6...7...8...9...10 Bounce #2 added RGB(79085, 62099, 28859) 0...1...2...3...4...5...6...7...8...9...10 Bounce #3 added RGB(15652, 11540, 4505) 0...1...2...3...4...5...6...7...8...9...10 Bounce #4 added RGB(3314, 2313, 772) 0...1...2...3...4...5...6...7...8...9...10 Bounce #5 added RGB(764, 504, 144) 0...1...2...3...4...5...6...7...8...9...10 Bounce #6 added RGB(182, 114, 29) 0...1...2...3...4...5...6...7...8...9...10 Bounce #7 added RGB(45, 27, 6) 0...1...2...3...4...5...6...7...8...9...10 Bounce #8 added RGB(11, 6, 1) 0...1...2...3...4...5...6...7...8...9...10 Bounce #9 added RGB(3, 2, 0) 0...1...2...3...4...5...6...7...8...9...10 Bounce #10 added RGB(1, 0, 0) Build Patch/Sample Hash Table(s).....Done<0.2943 sec> 0...1...2...3...4...5...6...7...8...9...10FinalLightFace Done 0 of 0 (0% of) surface lights went in leaf ambient cubes. ComputePerLeafAmbientLighting: 0...1...2...3...4...5...6...7...8...9...10 Ready to Finish Object names Objects/Maxobjs Memory / Maxmem Fullness ------------ --------------- --------------- -------- models 17/1024 816/49152 ( 1.7%) brushes 3880/8192 46560/98304 (47.4%) brushsides 27609/65536 220872/524288 (42.1%) planes 13044/65536 260880/1310720 (19.9%) vertexes 23980/65536 287760/786432 (36.6%) nodes 2411/65536 77152/2097152 ( 3.7%) texinfos 2404/12288 173088/884736 (19.6%) texdata 436/2048 13952/65536 (21.3%) dispinfos 25/0 4400/0 ( 0.0%) disp_verts 1969/0 39380/0 ( 0.0%) disp_tris 3104/0 6208/0 ( 0.0%) disp_lmsamples 150380/0 150380/0 ( 0.0%) faces 11559/65536 647304/3670016 (17.6%) hdr faces 11559/65536 647304/3670016 (17.6%) origfaces 8315/65536 465640/3670016 (12.7%) leaves 2429/65536 77728/2097152 ( 3.7%) leaffaces 15509/65536 31018/131072 (23.7%) leafbrushes 7950/65536 15900/131072 (12.1%) areas 4/256 32/2048 ( 1.6%) surfedges 92005/512000 368020/2048000 (18.0%) edges 61028/256000 244112/1024000 (23.8%) LDR worldlights 345/8192 30360/720896 ( 4.2%) HDR worldlights 345/8192 30360/720896 ( 4.2%) waterstrips 2062/32768 20620/327680 ( 6.3%) waterverts 0/65536 0/786432 ( 0.0%) waterindices 37176/65536 74352/131072 (56.7%) cubemapsamples 319/1024 5104/16384 (31.2%) overlays 55/512 19360/180224 (10.7%) LDR lightdata [variable] 7506712/0 ( 0.0%) HDR lightdata [variable] 7506712/0 ( 0.0%) visdata [variable] 65923/16777216 ( 0.4%) entdata [variable] 261093/393216 (66.4%) LDR leaf ambient 2429/65536 58296/1572864 ( 3.7%) HDR leaf ambient 2429/65536 58296/1572864 ( 3.7%) occluders 8/0 320/0 ( 0.0%) occluder polygons 48/0 576/0 ( 0.0%) occluder vert ind 208/0 832/0 ( 0.0%) detail props [variable] 1/12 ( 8.3%) static props [variable] 1/89920 ( 0.0%) pakfile [variable] 27847578/0 ( 0.0%) Level flags = 0 Win32 Specific Data: physics [variable] 1295790/4194304 (30.9%) ==== Total Win32 BSP file data space used: 48560792 bytes ==== Total triangle count: 35590 Writing c:\program files\valve\steam\steamapps\sourcemods\offlimits\maps\ol_styx.bsp 1 hour, 7 minutes, 52 seconds elapsed Thanks !
Zacker Posted December 13, 2006 Report Posted December 13, 2006 I can't think of any reasons why a street or sidewalks should be func_detailed. Rule of thumb is that obstacles and small details should be func_detail, rest world brushes. Your log looks fine. A v_weapon model's lighting is determined by 2 things: - The light info from the lightmap patch directly below the origin/pivot of the model. - The nearest cubemap.
hessi Posted December 13, 2006 Report Posted December 13, 2006 I can't think of any reasons why a street or sidewalks should be func_detailed. Rule of thumb is that obstacles and small details should be func_detail, rest world brushes. Your log looks fine. A v_weapon model's lighting is determined by 2 things: - The light info from the lightmap patch directly below the origin/pivot of the model. - The nearest cubemap. there is one big reason: keeping vis leaf structure as simple as possible. if you have sidewalks as a regular brush it will create 3 leafs: one above the sidewalk, one above the street with the height of the sidewalk and a third leaf that is right above the last leaf. if you make the sidewalk a func_detail you will get everything running with only 1 leaf.
Wesley Tack Posted December 14, 2006 Author Report Posted December 14, 2006 did you buildcubemaps? yea, Keats, the main coder thinks i could be what Zacker said: - The light info from the lightmap patch directly below the origin/pivot of the model. This would mean that the player model casts it's shadow on the weapon(..?!..), and when you look up or jump the weapon lights up. So far it makes sense, he will do some tests on this asap. I'll let you know as soon as we got some concrete information.
Zacker Posted December 14, 2006 Report Posted December 14, 2006 Correct Hessi, it would indeed simplify the leaf structure. It would however also require the road(or another world brush) to be extended to go below the sidewalk. I believe that those extra polygons are more expensive than a slightly more complicated leaf structure in most cases. Anyone who knows of some accurate tests on this subject or are willing to perform some? WesleyTack, I don't think that the player model shadow affects the weapon as it is not affecting the lightmap. I am not sure about this one though and your results seem to prove otherwise.
hessi Posted December 14, 2006 Report Posted December 14, 2006 why using extra polygons? you could use the same brush and polycount as before. nodraw backfaces and extending the ground wouldnt mean to dublicate brushes.
Zacker Posted December 14, 2006 Report Posted December 14, 2006 Same brush I am aware of yes, but the part below the sidewalk would also be drawn and give extra polygons. Applying nodraw to that part would eliminate the problem yes, but how would you apply nodraw to one part of of a face while retaining the correct texture on another part of the same face?
hessi Posted December 14, 2006 Report Posted December 14, 2006 no. that wasnt what i was talking about. i made a quick visualisation of what i mean: http://www.thomashess.net/func_detail_usage.jpg as you can see the ground is just a little bit bigger than it is actually visible. it is true that you will waste some lightmap space and rendering time on those polygon parts (!!!!) but your polycount won't get bigger. i think this is a pretty good way to simplify your leaf structure to get rid of tiny leaves. steppenwolf once said: a map should not take more than 5 minutes to compile vis in full mode. (or was it 30?) anyway. what this means, that a simple leaf structure will make it easier for you to optimise visibility. decompile some of valves dod:s maps and you will notice that they kinda made half the levels func_details. they actually displaced some sidewalks which means a bunch of extra polygons. and btw: polycounts are kind of overrated. it doesnt make a big difference if you render 100 or 10 polygons. so i think the method i posted is pretty good for a fast compiling process and good ingame performance
Recommended Posts