vrad.exe commands and other advanced lighting techniques + how to properly light foliage in Source -

[Grenade Man]

[I]Important: this tutorial is intended for Source 2013 based games (Garry's mod, HL2, DOD:S...) and some advice mentioned here might be obsolete in regard to the latest Source games (Insurgency, CS:GO etc.)[/I]

This tutorial intends to teach you how to utilize advanced lighting techniques (especially vrad.exe commands) in order to achieve quality lighting for prop_static models in the Source engine.

There's four main topics that we are covering:
1) vrad.exe commands
2) prop_static properties
3) other useful tricks
4) lighting foliage

[B]1) vrad.exe commands, how to use them, what do they do, and what are their problematic effects[/B]

So right off the bat here's the holy trinity:
-StaticPropLighting
-StaticPropPolys
-TextureShadows

[QUOTE]To continue, you should be familiar with with the [I]Hammer expert compile dialog[/I]
Here are some useful lings from the VDW:
[url]https://developer.valvesoftware.com/wiki/Expert_compile_mode[/url]
[url]https://developer.valvesoftware.com/wiki/Hammer_Run_Map_Expert[/url][/QUOTE]

Once you understand how to properly add these commands to vrad.exe, we can continue.
[I]note: I recommend you create your own compile configuration by copying the "HDR full -final" configuration, so you don't accidentally mess up your default configuration[/I]

[B]-StaticPropLighting[/B]
[QUOTE][I]Generate per-vertex prop_static lighting; always enabled for light_spot entities. Disables info_lighting entities on props WITHOUT normal maps. Does not work on props with Phong Enabled.[/I][/QUOTE]

Unlike the other two commands, this command affects the way static props [I]receive [/I] lighting.
[QUOTE]By default, static props are lit similarly to dynamic models. In short, they get their entire lighting from the nearest [URL="https://developer.valvesoftware.com/wiki/Ambient_light"]ambient light sample point[/URL]. This looks acceptable for most small props, and is insanely fast performance-wise compared to contemporary lighting solutions.

However, this can end up looking very bad in the following situations:
-large props that should visibly receive shadows from other objects
-props located in a non-uniform lighting situation, any more complicated light setup, especially in detailed set pieces (example: large teleporter in Black Mesa's end sequence)
-environments that don't have a lot of brush geometry, situations where models and displacements make up most of the map (such as a forest), because [URL="https://developer.valvesoftware.com/wiki/Ambient_light"]ambient light sample point[/URL] generation depends on world brushes[/QUOTE]

-StaticPropLighting enables detailed lighting on prop_static models, much similar to lightmap shadows, only the lighting information is stored for every vertex of the model and blended between them. This means that the more vertexes a model has it will have more detailed lighting.
This makes it possible to solve most of the problematic situations mentioned above, and then some.
But, don't get your hopes up. This isn't going to give you crysis-level lighting on props neither will it do miracles. It is just a crude solution to a 2004 engine's problems.

The -StaticPropLighting command enables the effects on all props, but [I]this type of lighting can the be disabled per-object in every prop_static's properties tab.[/I] See the drawbacks section on why you would want to do this.

For lighting foliage, -StaticPropLighting is very important because it enables the use of another super-useful command in a static_props properties, as explained in section 2) of this tutorial

[I]Examples: (I take no credit for the following images)[/I]
[QUOTE](only compare the first and last panel, observe the barrel that receives a shadow)
[IMG]http://www.nodraw.net/wp-content/uploads/2010/12/lighting_case_ex2-700x394.jpg[/IMG]

(a large model in a complex lighting situation - the textbook situation for using -StaticPropLighting)
[t]https://www.mapcore.org/uploads/monthly_2015_08/cheap_model_lighting_oriented_example.jpg.38f504656758b78d704ccc9aadf3b94f.jpg[/t]

(lighting quality depends on vertex density)
[IMG]https://www.mapcore.org/uploads/monthly_2015_08/simple_mesh_complex_mesh_comarison.png.7194aba59303b0e33e81a9e352640a85.png[/IMG][/QUOTE]

[I]Drawbacks:[/I]
- using -StaticPropLighting can greatly increase your .bsp's filesize. This depends on how many models are using the effect. You should disable it in a prop_static's properties whenever you aren't 100% sure it is needed, especially for smaller props.
- -StaticPropLighting is incompatible with many shaders. Most importantly, it can not work when the model in question has a bumpmap, or uses phong
- sometimes -StaticPropLighting actually makes a models lighting look worse. In these situations you should revert to default lighting and try to solve the problem with info_lighting entities.

[B]-StaticPropPolys
-TextureShadows[/B]
[QUOTE]
-StaticPropPolys
Perform shadow tests of prop_statics at polygon precision. Default is to use collision meshes.
[I] Note: When using this command in Source 2013, static props that don't have .dx80.vtx files won't be compiled with lightmapped shadows.[/I]

-TextureShadows
Generates lightmap shadows from $translucent surfaces of models (NOT brushes) that are specified in a lights file and being used with prop_static. Usually requires -StaticPropPolys to have any effect.
[/QUOTE]

Unlike -StaticPropLighting, these commands affect the way prop_static models [I]cast [/I] shadows
[QUOTE]By default, for the sake of making compile times shorter, the compiler generates prop_static shadows using the prop_static's collision model. This surprisingly looks fine most of the time, but here is when it fails to look convincing:
- on large complex models with simple collision models (especially background models)
- on foliage, because typically only the trunk has a collision mesh
- on chain link fences, because the mostly transparent fence has a opaque collision model[/QUOTE]

-StaticPropPolys enables the compiler to use the full mesh for computing shadows, still not taking into account textures. It increases compile times, but most of the times it is worth it. Every released map should be compiled using this command.
[QUOTE] -StaticPropPolys still doesn't take into account texture transparency. Foliage will cast shadows that are too sharp and abrupt, while the chainlink fence problem wont be solved at all.[/QUOTE]

-TextureShadows enables the compiler to use a models texture transparency for casting shadows. The effect must also be enabled per-model in a .rad file
-StaticPropPolys must also be used or -TextureShadows wont work!
[QUOTE][I]IN ORDER FOR TEXTURE SHADOWS TO WORK FOR A MODEL, THE EFFECT MUST ALSO BE ENABLED FOR THAT MODEL IN A .rad FILE[/I]

[url]https://developer.valvesoftware.com/wiki/VRAD#Lights_files[/url]
There are 3 types of .rad files. All of them work the same way, they just differ in name and location. It doesn't matter in which one you enable a model, but make sure the .rad file you use is loaded on compile.

To enable a model to use textureshadows, you must add

forcetextureshadow MODELPATH.mdl

to any loaded .rad file.

[I]IT IS CASE SENSITIVE; COPY THE LINE FROM HAMMER BUT REMOVE THE "models/" PART.[/I][/QUOTE]

The reason why -TextureShadows must be specifically enabled for every model is because it takes a loong time to compute. If you are making a forest where every tree uses textureshadows, expect very long compile times even with large lightmap sizes and good hardware.
Textureshadows make a difference even when you are using large lightmap sizes. Without textureshadows you will have dark splotches around most foliage, while textureshadows will even out those dark spots and make the lighting more uniform.
[QUOTE][IMG]http://www.nodraw.net/wp-content/uploads/2010/12/lighting_case_ex1-700x394.jpg[/IMG][IMG]http://www.subtleallusion.com/blog/wp-content/uploads/2010/12/lighting_case_ex3.jpg[/IMG][/QUOTE]

[I]Drawbacks:[/I]
- (significantly) longer compile times
- thats it

[I]Note:[/I]
- it is recommended that you don't use these commands during development, and only add them when compiling a finished map for release
- as a rule of thumb, every released map should be compiled with these parameters

[B]2) prop_static properties[/B]
[IMG]https://developer.valvesoftware.com/w/images/thumb/a/ab/L4d_hammer_entity_05.jpg/500px-L4d_hammer_entity_05.jpg[/IMG]

[B]Disable Shadows[/B]
Nothing special to say here, but worth a mention. Many problems can be avoided by disabling shadows, and if the mapper is cunning enough, the player wont notice it at all. You can also create fake shadows using blocklight textured brushes.

[URL="https://developer.valvesoftware.com/wiki/Info_lighting"]Lighting Origin[/URL]
Not covered in this tutorial. This is basic stuff I guess

[B]Disable vertex lighting[/B]
Can be used to disable the -StaticPropLighting command for a specific prop. When in doubt, set it to [I]yes[/I]

[B]Disable Self-Shadowing[/B]
Prop will not cast shadows on itself when -StaticPropLighting is enabled. Best set to [I]no[/I] unless it causes visual errors. This can be set to [I]yes[/I] to avoid some lighting glitches.

[B]Ignore surface normal for computing vertex lighting[/B]
[I]Only works with -StaticPropLighting [/I]
Now this is a often overlooked and super-important setting. The official explanation is: "A surface normal defines the direction from which each polygon is brightest-lit, and how much light is received."
Without going too much in-depth: [I]SET THIS TO YES FOR ALL TREES,BUSHES,GRASS AND OTHER FOLIAGE MODELS[/I]
It is used to fake subsurface scattering in leaves and grass.
[I][to do:screenshot examples] [/I]

[B]3) other usefull tricks[/B]

[I]to do[/I]

[B]4) techniques for lighting foliage:[/B]

Foliage models should be prop_statics in most cases
-StaticPropLighting should be enabled
-StaticPropPolys and -TextureShadows ought to be enabled also, with all your foliage models added to .rad files so they cast textureshadows
"Ignore surface normal for computing vertex lighting" set to [I]yes[/I] for all foliage models in prop_static's settings
Depending on the way the foliage has been modeled, it might be required to "Disable Self-Shadowing" for it. Do some tests and see what works best for you. If in doubt, set "Disable Self-Shadowing" to [I]no[/I]

[I]to do: expand this section[/I]

Usefull resources:
[URL="https://developer.valvesoftware.com/wiki/VRAD"]VDW: vrad.exe[/URL]
[URL="http://www.nodraw.net/2010/12/lighting-compile-options/"]Nodraw.net[/URL]
[URL="http://www.interlopers.net/tutorials/27738"]Interlopers[/URL]
[URL="https://www.mapcore.org/articles/development/source-lighting-technical-analysis-part-two-r66/?&tab=comments"]In depth analysis od staticproplighting @ mapcore[/URL]
[URL="https://developer.valvesoftware.com/wiki/Advanced_Lighting"]VDW: Advanced Lighting[/URL]
[URL="https://tf2maps.net/threads/staticproplighting-and-why-not-to-use-it.5077/"]Filesize issues[/URL]

[Kemerd]

I've been using these for a while; but the only thing tipping me off was on the VRAD wiki page. I know a lot of mappers don't use these VERY important settings (and should).

What a great and extensive guide! :)

Please keep in mind though, using -staticproppolys on a L4D2 file that only has .dx90 files will crash your game. To fix this, copy the .dx90 file and rename it to .dx80; or use this guy's amazing custom map compilers: [url]https://facepunch.com/showthread.php?t=1552397[/url]

His compilers have LAA and a bunch of model fixes (lets you compile staticproppolys on a prop_static that is using a "dynamic only" model, etc).