Self-Contradictory Lighting Error

Gnostici

L1: Registered
Aug 16, 2011
5
0
I have a surface with only one light on it. This is set up intentionally -- it's a hallway with light_spot entities that are turned on sequentially by a trigger.

Two things are happening here that make no sense. With five identical lights, each with their own hallway segment to ensure no face lies within the cone of two lights, I get "WARNING: too many light styles on a face at..." There is only one light on each face.

The compiler seems to pick on two lights in particular that are no different in any way from the other three lights. In game, every light renders on every face except for one for each of the two lights that produce the error. The other three are fine, and these lights are identical in all but name.

I've lost count of the hours I've spent trying to figure this out. If I delete every single other light in my map, it still does it. If I copy others and rename them, it still does it. If I delete these lights and their hallway segments then rebuild them, ditto. Same if I move them away from the rest of the map.

Proof:

eLp1T.jpg

PRt9c.png


I'm officially stuck here. I can find no reason that this should be happening.
 
Last edited:

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
Light bounces further than you think. If you don't want to alter anything design-wise, you will probably have to make use of the maximum cutoff distance that lights have. That should absolutely ensure the light doesn't go farther than you need.
 

Gnostici

L1: Registered
Aug 16, 2011
5
0
I tried that too. I used a brush to measure the distance to the wall (65), and set the cutoff to that.

edit: Sleep works miracles. I've found a way to make it work by using the 50% and 0% falloffs, along with the hard falloffs. That gives me a few experiments to do, but this is doing the trick! I got all the lights to render!

Lighting is just about the most important thing in a map. It can be used (if you're creative) to change the colors of things, which has big applications in creating new kinds of matches (or expanding old ones). It can be used to make your setting believable, and it can wow players. It can also destroy a map. Opening Hammer and running with it leads to lots of experimentation needed to work it out. Yet the most comprehensive lighting tutorials I can find seem to throw back to HL2 around 2007 or 2008.

So, I'll be writing an in-depth lighting tutorial that shows how to accomplish everything special I do in this map. Expect great things, if I don't whittle my fingers to nubs working it out in the meantime lol
 
Last edited:

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Well people mapping for TF2 don't generally need to know more about lights other than how to change the brightness setting or use of tex-lights.

Colour theory is colour theory whether you read it on a level design forum or got taught it in art class; but the consensus here is that coloured lights are just generally bad. Coloured lights mess with team recognition and lights that turn on and off are even worse as Source does not handle dynamic lighting very well, even impacting on performance negatively.

In multiplayer play flashing lights are distracting, unnecassery and interfere with gameplay. Coloured lights (as previously mentioned) also negatively impact on gameplay through team recognition which is also a problem for poor lighting such as low brightness settings in dark rooms (dark textures bounce less light back during the vrad process).

So you only really need to know three things when doing your lighting for TF2:
  • Your map must be well lit for player recognition.
  • Nothing more than a subtle change in ambient RGB to maintain quality team recognition.
  • No dynamic lights because generally they look bad and impede on performance.
 

Moose

L6: Sharp Member
Nov 4, 2009
312
616
Pretty much what grazr said, although tinting fluorescent/incandescent lights slightly is good practice.