Geodome lighting glitch
I want to solve a heavy problem that we all encounter: the lighting of the spheres looks incredibly wrong.
But here's the interesting fact: by decompiling and recompiling Valve's stuff, you will get the same issue.
They obviously use special settings for VRAD while compiling. I tried with -StaticPropLighting and it looks way better, but some shadows are still too hard. I think they used a method to cast finer shadows, because interestingly my recompiled map weighs 9.9 Mb and theirs weighs 18.4 Mb. The map is called "sp_a3_bomb_flings".
Here are the results:
Original:
normal compiling:
-StaticPropLighting applied:
As you can see, the last one is nearly perfect, but the shadows are too hard. Look at the railing for an example.
Any idea to get the perfect result?
Did you also use the "-final" option?
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
I just tried and it doesn't seem to change anything. The file still weighs 9.9 Mb by the way.
PS: I'm using fast VIS because otherwise it would take hours. Does it affect the file's size?
Gah. I hate that glitch.
Did not know about -StaticPropLighting. I'll try it out next time I compile my Old Aperture maps.
I don't remember sp_a3_bomb_flings being in the Source SDK examples.
Are you recompiling a vmf that you decompiled from the 'official' bsp? In that case, some settings may be lost during the decompilation and cause your version of the map to be different from Valve's.
For example, it may be that the luxel density on all surfaces is reset to 16, which would explain the dark shadows near the railing.
You can perhaps try compiling sp_a3_speed_ramp.vmf from the Source SDK examples and see if it looks better.
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Yes I used a decompiled map, I know it's not a good idea... But it looks like it's not because of the luxels. I just checked the luxel density in game:
Original:
Recompiled map:
It looks the same but check out the railing's shadows.
I also tried to compile "sp_a3_speed_ramp" which has not been decompiled, and the same issue appears: the obtained map is 9 Mb while Valve's map is 18 Mb.
I'm totally sure it has something to do with the compiling settings.
Thanks for helping by the way.
use the -textureshadows command also. it detects alpha textures. might help.
[spoiler][SP] Alternate[/spoiler]
It just detects alpha textures on models. And then just models specified in the RAD file.
Oh and for me your shadows look like Valves shadows. The map size can be different because I think you didn't build cubemaps! And these can add some more mb to your map.
Oh of course, that does explain the size difference. Thanks Skotty!
I just looked in my standard compile options and there is another option: "-StaticPropPolys". You have to use that one also because otherwise all static props (railing or otherwise) cast a shadow of their collision volume instead of the mesh itself. So the full command would be:
- Code: Select all
vrad.exe -both -final -textureshadows -StaticPropLighting -StaticPropPolys %projectFile%
(where %projectFile% is the file name of your vmf.)
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Yes you were right! The ugly sahdows were actually casted from the collsions models. Using your command works perfectly. The file is now heavier and the compiling time is kinda long but that's the proper way to do.
Here's the result:
Thanks everyone. Now that we solved this, I think we should have a sticky note about "how to avoid lighting glitches" or something. Every underground themed map I played had similar glitches, so I think we should.