Dark spots in my map

Seitan

L3: Member
Oct 30, 2015
135
8
Help
019qYCW.jpg

exzoLWQ.jpg

This one doesn't happen in the BLU side of the map ^ ^ ^
SfR8811.jpg

WngmomP.jpg


This is how they look in the editor:
uOw0W8L.png

b7b81c99-d9d4-42a8-9507-eade532bdd7c
GZklvWT.png

Evw9Cga.png

G7P4YBk.png
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
You also probably shouldn't be spreading out your lights so far in an attempt to light stuff directly. Let the extra bounces of -final do the work for you.
 

Seitan

L3: Member
Oct 30, 2015
135
8
You also probably shouldn't be spreading out your lights so far in an attempt to light stuff directly. Let the extra bounces of -final do the work for you.
So this may be automatically fixed in the final compile?
 
Mar 23, 2013
1,013
347
No it's not. the -final compile only uses the "-final" command which is equal to "-extraSky 16". It just fires more rays from the sky, making the light_enviroment lighting more accurate.

What the three other commands from the article do is:
1: Instead of having a single point for each model to calculate it's shadowing, the entire model is used and it will be lit like it makes sense.
2: Instead of the unacurate colision model, the actual model will be used to calculates shadows with.
3: If a model has a transparent texture it will now properly let light through at points where it is transparent.
Oh, and there is the custom .rad file thing, but that's only useful when you really want to use its features, so you probably don't need to worry about it for now.

Dunno why Valve didn't add those extremly important commands to one of the advanced compile options, but you wouldn't want to only have these compile options with the -final compile because -file will extend your compile time massivly while the other lighting options only make your compile by 15-30% longer.
Also setting up your own compile options makes you able to quickly switch between compile options. What I do is having a vvis compile for normal and one for fast, and then make vrad compiles for:
-fast -hdr
-hdr -staticproppolys -textureshadows
-staticproplighting -lights customlights.rad
-both -staticproppolys -textureshadows -staticproplighting -lights customlights.rad
-both -staticproppolys -textureshadows -staticproplighting -lights customlights.rad -extrasky 16

upper one is a basic test with bad lighting, second one is better lighting but HDR only because my game is in HDR, third one is also for testing however compile for both HDR & LDR so it can be tested on a server where some players may have LDR and finally the 4th option is the final compile.

Now I guess you could probably just the command to the -final compile and never bother with it again until you want to compile for final, however if the final compile still has some weird shadowing in a place you would just end up with long compile times just to change some shadows, so try setting up your own custom cpmpile with more options to be more efficient
 

MOCOLONI

L6: Sharp Member
Dec 16, 2014
373
89
This may not be the proper way of fixing it, but it's how I fixed these errors in my maps:

1. The shadow on the first screenshot is usually caused when the lamp's prop has its shadows enabled, which should be disabled if it draws these shadows.

2. For the 'darker props' case, it's because their origin isn't reached by the light that is supposed to illuminate them, so I would spawn an info_lighting entity next to the prop that is illuminated properly, and set the darker prop's lighting origin to use the one by the info_lighting entity. It works fine for me, and is also the way Dustbowl got some of its rocks darkened/illuminated in the official VMF.
 
Mar 23, 2013
1,013
347
For the 'darker props' case, it's because their origin isn't reached by the light that is supposed to illuminate them, so I would spawn an info_lighting entity next to the prop that is illuminated properly, and set the darker prop's lighting origin to use the one by the info_lighting entity. It works fine for me, and is also the way Dustbowl got some of its rocks darkened/illuminated in the official VMF.

No offense, but please stop recommending this method over the compile options. It will still look worse than when using the proper lighting compile settings. All props will have a much more natural and accurate lighting to it and all shadows will be acurate too. Most notable improvements can be seen at the pinetree props.
 
Last edited:

Seba

DR. BIG FUCKER, PHD
aa
Jun 9, 2009
2,364
2,728
Using an info_lighting and keeping pervertex lighting off can sometimes look better than with pervertex on, -staticproplighting isn't a one-size-fits-all solution
 
Mar 23, 2013
1,013
347
True, but it's a better solution the vast majority of the time as all props will have better fiting lighting. Most of my maps never needed a info_lighting at all.
That's why I said you shouldn't recommend using an info_lighting over the compile settings, or epecially in this specifc case.
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
I thought -final caused lights to bounce more. I know there's some option that does, because recompiling 2fort with the base options leaves you with darker than normal spawn room ceilings.