Help please - hammer/vrad glitch

Riever

L2: Junior Member
Nov 25, 2011
86
4
Dear all,

I have been working on my map's awful lighting and have just rebuilt a set of mine tunnel lights. As this took a while and the map is mirrored I then selected them and copied to the other side.

Big mistake! D:

Now when I compile I find that some, not all, models are very dark - as if they are not being lit at all. These worked fine before I copied the lights (with the old dud lighting) and all the world and func_detail brushes are lit fine.

Has anyone any idea why this is? I fear I'm going to have to throw all my improved lighting away and redo it.

Ugh.
 
Last edited:

GPuzzle

L9: Fashionable Member
Feb 27, 2012
638
414
Well, you don't need fancy lighting until mid-beta, just a lighting that looks partially good. Otherwise, try compiling again.
 

henke37

aa
Sep 23, 2011
2,075
515
Did you name the lights?
 

Riever

L2: Junior Member
Nov 25, 2011
86
4
Hi,

Sorry compiling again produces the same odd result. Sadly I didn't name the lights either.

Very odd, and annoying.
 

Riever

L2: Junior Member
Nov 25, 2011
86
4
Don't name the lights. Are you sure lights aren't embedded in any props?

In a word ermm, no.

I don't have any named lights but I do have some mining lanterns which I have placed a light entity inside. The lamps are prop_dynamic with a render effect of glow. I disabled receiving shadows and collisions (not sure if the latter was needed) and then placed a light with a flicker appearance inside the lamp.

They look really good, and actually appear to be lit by the flame in the lamp, but could my doing this be causing the glitch? If so could you suggest how I can set the two entities (lamp and light) up so that it looks like the lamp is producing the light and not something thats elsewhere?

I also have a flooded tunnel and have placed some light entities in this, otherwise its pitch black. This means that the lights are embedded in a brush (although its a water brush)

Is this also wrong? :confused:

Thanks in advance.
 

Riever

L2: Junior Member
Nov 25, 2011
86
4
On closer inspection there are now a lot of odd things going on.

1. Light leaks - where two brushes join perfectly in Hammer but where light is leaking through a non-existant gap

lightleak.jpg


2. Odd displacement colouration. There is a green smudge on this arch, where did that come from? The texture has no green in it at all!

greensmudge.jpg


Bad lighting on brushes

oddblackbrushfaces.jpg


oddlighting.jpg

:confused:
 

Riever

L2: Junior Member
Nov 25, 2011
86
4
Here's a compile log


** Executing...

Valve Software - vbsp.exe (Sep 5 2012)
4 threads
materialPath: e:\steam\steamapps\\team fortress 2\tf\materials
Loading E:\Steam\steamapps\\WesternHoldUp_a20a.vmf
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
Patching WVT material: maps/westernholdup_a20a/nature/blendrockground001_wvt_patch
Patching WVT material: maps/westernholdup_a20a/nature/blendrockgroundwall003_wvt_patch
Patching WVT material: maps/westernholdup_a20a/nature/blendrockgroundwall004_wvt_patch
Patching WVT material: maps/westernholdup_a20a/nature/blendrockgroundwall001_wvt_patch
Patching WVT material: maps/westernholdup_a20a/nature/blendrockground002_wvt_patch
Patching WVT material: maps/westernholdup_a20a/brick/blendcobbletocobblesnow001_wvt_patch
Patching WVT material: maps/westernholdup_a20a/nature/blendcliffgrass001a_wvt_patch
Patching WVT material: maps/westernholdup_a20a/nature/blendrockground007_wvt_patch
Patching WVT material: maps/westernholdup_a20a/koth_viaduct_event/blendrockgroundwallforest_viaduct_event002_wvt_patch
Patching WVT material: maps/westernholdup_a20a/bankheist/lavablend_wvt_patch
Patching WVT material: maps/westernholdup_a20a/cp_mountainlab/nature/blendrocktograss002_wvt_patch
fixing up env_cubemap materials on brush sides...
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 (0)
Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 2026 detail faces...done (1)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (3)
writing E:\Steam\steamapp\WesternHoldUp_a20a.prt...Building visibility clusters...
done (0)
*** Error: Skybox vtf files for skybox/sky_well_01 weren't compiled with the same size texture and/or same flags!
Can't load skybox file skybox/sky_well_01 to build the default cubemap!
*** Error: Skybox vtf files for skybox/sky_well_01 weren't compiled with the same size texture and/or same flags!
Can't load skybox file skybox/sky_well_01 to build the default cubemap!
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 (2) (1720445 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 10783 texinfos to 5203
Reduced 215 texdatas to 198 (5393 bytes to 4688)
Writing E:\Steam\steamapps\WesternHoldUp_a20a.bsp
16 seconds elapsed

** Executing...
** Command: "e:\steam\steamapps\\sourcesdk\bin\orangebox\bin\vvis.exe"
** Parameters: -game "e:\steam\steamapps\k\team fortress 2\tf" "E:\Steam\steamapps\\sourcesdk_content\tf\mapsrc\WesternHoldUp_a20a"

Valve Software - vvis.exe (Sep 5 2012)
4 threads
reading e:\steam\steamapps\WesternHoldUp_a20a.bsp
reading e:\steam\steamapps\WesternHoldUp_a20a.prt
2276 portalclusters
6088 numportals
BasePortalVis: 0...1...2...3...4...5...6...7...8...9...10 (2)
PortalFlow: 0...1...2...3...4...5...6...7...8...9...10 (2726)
Optimized: 12275 visible clusters (0.92%)
Total clusters visible: 1337161
Average clusters visible: 587
Building PAS...
Average clusters audible: 1541
visdatasize:995870 compressed from 1310976
writing e:\steam\steamapps\WesternHoldUp_a20a.bsp
45 minutes, 28 seconds elapsed

\WesternHoldUp_a20a"

Valve Software - vrad.exe SSE (Sep 5 2012)

Valve Radiosity Simulator
4 threads
[Reading texlights from 'lights.rad']
[34 texlights parsed from 'lights.rad']

WesternHoldUp_a20a.bsp
Setting up ray-trace acceleration structure... Done (6.88 seconds)
18526 faces
10 degenerate faces
3107737 square feet [447514176.00 square inches]
571 Displacements
698473 Square Feet [100580160.00 Square Inches]
18516 patches before subdivision
300168 patches after subdivision
sun extent from map=0.008727
356 direct lights
BuildFacelights: 0...1...2...3...4...5...6...7...8...9...10 (169)
BuildVisLeafs: 0...1...2...3...4...5...6...7...8...9...10 (150)
transfers 32530709, max 1562
transfer lists: 248.2 megs
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #1 added RGB(2718450, 1909542, 1332808)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #2 added RGB(603137, 349690, 207392)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #3 added RGB(167272, 81663, 41559)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #4 added RGB(50473, 21260, 9259)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #5 added RGB(16659, 6073, 2240)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #6 added RGB(5833, 1852, 574)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #7 added RGB(2179, 597, 154)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #8 added RGB(849, 201, 43)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #9 added RGB(348, 70, 12)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #10 added RGB(147, 25, 4)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #11 added RGB(65, 9, 1)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #12 added RGB(29, 3, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #13 added RGB(13, 1, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #14 added RGB(6, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #15 added RGB(3, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (1)
Bounce #16 added RGB(1, 0, 0)
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #17 added RGB(1, 0, 0)
Build Patch/Sample Hash Table(s).....Done<0.1482 sec>
FinalLightFace: 0...1...2...3...4...5...6...7...8...9...10 (23)
FinalLightFace Done
0 of 0 (0% of) surface lights went in leaf ambient cubes.
ThreadComputeLeafAmbient: 0...1...2...3...4...5...6...7...8...9...10 (28)
Writing leaf ambient...done
Ready to Finish

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 87/1024 4176/49152 ( 8.5%)
brushes 4540/8192 54480/98304 (55.4%)
brushsides 35237/65536 281896/524288 (53.8%)
planes 24316/65536 486320/1310720 (37.1%)
vertexes 36747/65536 440964/786432 (56.1%)
nodes 6355/65536 203360/2097152 ( 9.7%)
texinfos 5203/12288 374616/884736 (42.3%)
texdata 198/2048 6336/65536 ( 9.7%)
dispinfos 571/0 100496/0 ( 0.0%)
disp_verts 19203/0 384060/0 ( 0.0%)
disp_tris 26720/0 53440/0 ( 0.0%)
disp_lmsamples 318004/0 318004/0 ( 0.0%)
faces 18526/65536 1037456/3670016 (28.3%)
hdr faces 0/65536 0/3670016 ( 0.0%)
origfaces 13439/65536 752584/3670016 (20.5%)
leaves 6443/65536 206176/2097152 ( 9.8%)
leaffaces 23512/65536 47024/131072 (35.9%)
leafbrushes 10505/65536 21010/131072 (16.0%)
areas 16/256 128/2048 ( 6.3%)
surfedges 148705/512000 594820/2048000 (29.0%)
edges 93978/256000 375912/1024000 (36.7%)
LDR worldlights 356/8192 31328/720896 ( 4.3%)
HDR worldlights 0/8192 0/720896 ( 0.0%)
leafwaterdata 1/32768 12/393216 ( 0.0%)
waterstrips 3080/32768 30800/327680 ( 9.4%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 54804/65536 109608/131072 (83.6%) VERY FULL!
cubemapsamples 0/1024 0/16384 ( 0.0%)
overlays 52/512 18304/180224 (10.2%)
LDR lightdata [variable] 15472180/0 ( 0.0%)
HDR lightdata [variable] 0/0 ( 0.0%)
visdata [variable] 995870/16777216 ( 5.9%)
entdata [variable] 324562/393216 (82.5%) VERY FULL!
LDR ambient table 6443/65536 25772/262144 ( 9.8%)
HDR ambient table 6443/65536 25772/262144 ( 9.8%)
LDR leaf ambient 30487/65536 853636/1835008 (46.5%)
HDR leaf ambient 6443/65536 180404/1835008 ( 9.8%)
occluders 0/0 0/0 ( 0.0%)
occluder polygons 0/0 0/0 ( 0.0%)
occluder vert ind 0/0 0/0 ( 0.0%)
detail props [variable] 1/12 ( 8.3%)
static props [variable] 1/67428 ( 0.0%)
pakfile [variable] 6385/0 ( 0.0%)
physics [variable] 1720445/4194304 (41.0%)
physics terrain [variable] 118101/1048576 (11.3%)

Level flags = 0

Total triangle count: 57347
Writing e:\steam\steamapps\WesternHoldUp_a20a.bsp
6 minutes, 29 seconds elapsed

** Executing...
** Command: Copy File
\WesternHoldUp_a20a.bsp"
 
Last edited:

henke37

aa
Sep 23, 2011
2,075
515
The ink spill error is a sdk bug. Jiggle the map around to fix it.

The light leak issue can be solved by either bumping up the light map resolution or by splitting the face.
 

xzzy

aa
Jan 30, 2010
815
531
Is that part jutting out in the first screenshot a func_detail? That's an issue with using them.. they don't cut faces and if the lightmap on the large wall is too low resolution, it looks like light is leaking through. Either make it a world brush, or cut the wall into two brushes.


Problems similar to what you see in the other two screenshots can be caused by misaligned lightmaps. In hammer, click on the word in the top left corner of one of the view panes and select Lightmap. This will change to a 3d view that shows the lightmap grid.. it's uncommon, but it is possible if they aren't aligned perfectly you can get seams. You can fix it by selecting a wall with the texture tool and alt+clicking on adjacent walls.

It could also be more func_detail related problems, is everything in those screnshots world geometry?
 

Riever

L2: Junior Member
Nov 25, 2011
86
4
The ink spill error is a sdk bug. Jiggle the map around to fix it.

The light leak issue can be solved by either bumping up the light map resolution or by splitting the face.

Thanks for this - I'll leave the smudge for now and move the map once its been play tested. Could be the rock bridge gets removed or moved after this in any case,

Is that part jutting out in the first screenshot a func_detail? That's an issue with using them.. they don't cut faces and if the lightmap on the large wall is too low resolution, it looks like light is leaking through. Either make it a world brush, or cut the wall into two brushes.

Yes the thing jutting out is a func_detail. splitting the large wall didn't fix this - but turning it to world did which I guess will just have to do and I'll have to live with a slower vvis compile for now till I finalise the lighting.


Problems similar to what you see in the other two screenshots can be caused by misaligned lightmaps. In hammer, <snip>

It could also be more func_detail related problems, is everything in those screnshots world geometry?

Well I put my brain back in on this when you asked if the walls were world brushes. They are not, they're on a func_brush which gets spawned. Thing is the lights are static, so I'm guessing this is why everything is dud as I'm confusing vrad. Dropping the bushes to the world fixes the lighting issue but I really need to be able to spawn this brush work as it''s inside the UFO which is not on the map all the time.

I don't really want to use dynamic lighting, due to possible lag issues, so Is there any way to bake lighting onto func_brushes?
 

xzzy

aa
Jan 30, 2010
815
531
func_brushes light just like any other brush and shouldn't need any special consideration.

The problems only tend to show up when you try to mix world geometry and brush entities together. They get processed at different times during the compilation process and this can result in visual glitches.

I wouldn't think dynamic lights are necessary, but I haven't seen your map so I don't know what's going on. You may discover the best option is to create a prop.. a prop_dynamic tends to handle movement and toggling rendering with a lot less fuss.
 

Riever

L2: Junior Member
Nov 25, 2011
86
4
Thanks for this. The outside of the ufo is a prop, well actually a set of them as I kept having collision mesh problems when it was just one. I was hoping to have brushes for the inside until I had completed the texturing so that the map could be play tested. might just put a basic cube in for now as a place holder and see what players feel about the map. Could be the ufo gets left out of the final version...
 

Riever

L2: Junior Member
Nov 25, 2011
86
4
Ok,

Still got an odd problem with lighting. In the below the stairs are a static_prop made using propper propper. The front risers are white and the flat steps are the same colour as the walls. As you can see they aren't rendering correctly at all.

The column is also a propper model and this is rendering correctly.

Have tried building cube maps and playing with vrad options (-staticproppolys etc)

If I take the stairs 'outside' so they are lit by env_light (sun) they are fine. They are dud if they are lit with light_sport or light entities.

duffmodellighting.jpg


Any ideas?
 

tyler

aa
Sep 11, 2013
5,102
4,621
Bad lighting origin. Either remake the prop and change the origin or use an info_lighting.
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
And your column is made with a Half-Life texture. The floor might also be; I can't be sure from the picture. A good rule of thumb is that if you don't recognize a texture from somewhere in an official map, it's not a proper TF2 texture.
 

Riever

L2: Junior Member
Nov 25, 2011
86
4
Thanks for the this Yyler, adding an info_lighting works. I'l read up on origins (had no idea they could cause this) and I'll probably remake the prop in any case once I get nearer to fixing the textures. RIght now I'm still blocking out.

Same goes for the column Steve, (which I dumped in the picture just there to show some models are OK). I wanted a stone texture for the, erm, stone, and don't really like the devel ones. There aren't that many tf stone textures, other than Egypt, so might have a go at making my own.