LUX for Source SDK 2013

LUX is a Shader Modification for the Source Engine.
It serves as a drag & drop materialsystem\ Replacement on the Source Engine SDK (2013).

Features

For more specific Details, see LUX Github Wiki.

Total Overhaul of the materialsystem\ Folder

Implementing LUX is intended to be as easy as possible.
To ensure this, all Changes have been restricted to the `materialsystem\` Folder.

Using Code from the Orange Box and Alien Swarm,
`materialsystem\shaderlib` has been reimplemented.
On LUX, it has been heavily modified to allow for some of the new Features.
Previously LUX was limited to the `materialsystem\stdshaders` Folder.
Due to the ShaderLib Implementation, it is now restricted to `materialsystem\`

Faster Shader Compiles

Large Portions of and entire Shaders have been rewritten.
To keep Visuals the same as Stock, often times they are forced to use the same mathematical Functions.
This didn't mean their Systems couldn't be entirely reevaluated.

All of the Shaders in LUX combined can be compiled in ~15 Minutes, even on dated Hardware.
These are some of the CPU's LUX has been compiled with, in well under 15 Minutes:

• R7-7530u
• AMD Fx8350
• i7-6700k
• i7-5600U

Newer Hardware (R9-5950x), can go down to as low as 3-4 Minutes.

Various Shaders now also have their own .bat Scripts.
If a specific Shader is being modified, it will be faster to compile the subset of Shaders instead.
This is an Issue alluded to in the Stock common_ps_fxc2.h // This file is here so you can add new utility functions without // changing common_fxc.h and causing a recompile of the entire universe.
In Addition to this, Header Files are now more or less minimalistic.
This avoids the constant parsing of monolithic File Structures, often filled with unused Functions, on every Shader Combo.
There are some Exceptions to this like the LUX EnvMap Header which has a lot of Functions to handle the large Amounts of Features that EnvMaps support..
If you write new Shaders, splitting Features by Headers and Functions is suggested.

Compatibility with Mapbase

LUX aims to be a viable Replacement for Mapbase Shaders.
Because of this, specific Features have been added to accomodate it.
Some of the Features from Mapbase require modifying Client.dll and/or Compilers.

If you are planning on using a Feature otherwise only available with Mapbase you will have to port these yourself.

• Parallax Corrected Cubemaps require a custom VBSP.
• Treesway requires a custom Client.dll on SDK2013SP.
• Radial-Fog only controllable via ConVar on SDK2013SP.

To facilitate LUX working on Mapbase,
every Shader has SDK_ Fallbacks that lead to the LUX_ Variants.

Selective Stock Shader Replacement

Anyone who has touched the TF2SDK in recent Days,
will have noticed that the VPC Setup isn't exactly great.
Some People had Issues compiling Shaders like Core for ps20b because of new Instructions..
To replace a Shader, it has to be added to the Project in VPC.
This has two major Downsides.

1. Need to regenerate the Solution File, everytime a new Shader is to be replaced.
2. Some Shaders use other Shaders as a dependency.
   This sometimes makes it impossible to be selective.
   

**LUX** solves both of these Issues.
It provides a Headerfile with Defines that allow for the selective replacing of Shaders (Among other Things).
By Default all available Shaders are contained in the Project.
Having to mess with the VPC Scripts to add an existing Shader is not necessary.

**NOTE**:
SDK2013SP does not allow for the replacement of Stock Shaders.
Using Various Methods ( Memory Patches, the Material Passthrough Method ),
the replacement Functionality may be used on SDK2013SP.
Replacing Stock Shaders is optional, all LUX Shaders are using the LUX_ Prefix, Stock Shader Replacement is handled via Fallback Shaders.
The same goes for SDK_ Shaders. They fallback to LUX_.

Shadermodel 3.0 only

To allow for many of the new Features, all of the Shaders now use Shadermodel 3.0.
A Limitation created by this is that Linux on Source 2013 Singleplayer cannot run LUX.
This is a ToGL Limitation ( Translation-Layer ).
Support for SM3.0 on ToGL was added in Team Fortress 2,
but it never made it's way to SDK2013SP.

• DXVK may serve as an alternative here for Linux Users.
  
• SM3.0 released in 2004, Valve considered ps2.0b low end hardware in ~2008.
  
• Three DirectX Versions have released since DX9.
  
• The Shadercompiler on the TF2SDK doesn't even allow Shaders below < ps20b anymore.
  Meaning you couldn't add support for DX8 if you wanted to.
  

Older hardware that is not capable of running SM3.0 will not be able to use the new Shaders.
There are no Fallbacks for DX8 and DX7 and DX6.
NOTE: If you have an Intel integrated CPU that DOES support SM3.0 but has Issues, run with -force_vendor_id 0x10DE -force_device_id 0x1180

Documentation on Shaders and Parameters

Due to the Development of LUX, Articles on the VDC such as $lightwarptexture, $detail, UnlitTwoTexture and $envmapmask received massive updates, detailing new information about Caveats and Bugs.
LUX Shaders themselves are heavily commented - sometimes more than necessary..
Structural Comments ( Section Separation ) have been added to every Shader to clearly differentiate the different Systems.
Draw Functions have been organised to reflect this Change.
Shaders now follow clearly defined Patterns/Layouts, which makes it easier to find Things in a Shader and to make new ones by following the provided Structure.
Instances where some whacky Behaviour from Stock-Shaders has to be considered to keep visual consistency, have been commented with "Stock-Consistency".

On this Repositories Wiki you can find a List of all Shaders and their Parameters.
It also details how you can write new Shaders in the LUX Environment.
Porting existing Shaders is not recommended.
The whole Point of LUX is to remove all the old Things and get a fresh Start.
If you choose to adapt a Shader to LUX anyways, please reach out if you need Help or share the Things you had to change and how so we can (try to) document this on the Wiki.

Several Console Commands have been added to help with Documentation.
One of them allows dumping Information about Shaders in the .dll in a markdown ready Format. ( See also the Wiki )
Shaders now list in ( to varying degrees of Detail ) what Geometry they are made to support and what Limitations apply.

Helper Strings have been added to all Parameters.
They are massively more documented compared to their stock Variants.
Texture Parameters detail their Channel-Usages, other Parameters define their Size and Type.
Internal Shader Documentation can be looked at using the in-game Console as well. ( See also the Wiki )

Features previously unavailable to Source 2013

Various Features from other Branches have been implemented or recreated.
This includes older Features, such as $SelfIllumTexture and $EnvMapSphere.
Newer Features like $PhongAlbedoBoost (only in CS:GO) have been approximated.
NOTE: Features like `$SSBumpMathFix have been derived from visual research and logical conclusions, using the Games the Features are from as a visual Reference.
( Left 4 Dead 2, CS:GO, Portal 2 .. )
A lot of People helped in this Endeveaour.
by providing Reference Images, testing these Features and comparing to Branches with these Features.
Some even ported entire Maps from Left 4 Dead for their Mod Projects,
Going as far as replicating the common Infected themselves from both L4D1 and L4D2.

Fixing Bugs, Caveats, and missing Combos

LUX addresses many of the Issues Stock Shaders are known for.
From straight up missing or broken Features, to whacky stock Behaviour.
There is a lot to cover, so much that it's not possible to representative Examples.

If there is something you want fixed, check if it is!
NOTE: Some fixes may be locked behind certain Material Parameters ( like $PhongNewBehaviour ).
Going through the Parameter List for the Shader is recommended.

VERY IMPORTANT:

(26.01.2026 DMY):

SM30 Constant Registers don't work as intended in either SDK's
We have gotten multiple Confirmations that this will get fixed.
Spoiler: Among other Issues ( Cough Save-Restore ) this hasn't been fixed after Months.
Release will not be delayed by empty Promises, here's what this means for LUX Users.

Until this gets fixed for the TF2SDK:

• Your Game crashes on Launch if UnlitGeneric uses Registers above c31.
  Lux UnlitGeneric does not use Registers above c31 to account for this.
  
• Your Game crashes on Exit if any Shader used above c31.
  The old SDK2013 will crash if you use Registers above c31 at all.
  
  

This can be resolved right now for both SDK's by overriding Hardware Caps using Memory patching
LUX has a no-RE and no-Leak Rule thefore this is not provided with the LUX Repo. Sorry!

You can find the Patch for SDK2013SP at SDK2013CE.
You can find the Patch for the TF2SDK at Srcbox

Build instructions

Steps for building LUX:

1. Run src\materialsystem\stdshaders\!Compile_All.bat to compile all the Shaders.
   The Time this takes depends on your Hardware. This Step is CPU intensive.
   

2. Run createallprojects.bat to generate the .sln Solution File.

3. Compile the game_shader_generic_example.dll using the 'Shaders' Project in the .sln File.
   ( This results in a game_shader_dx9.dll for SDK2013SP )
   

4. Copy the compiled Shaders found in game\mod_tf\shaders\fxc\ to your mod\shaders\fxc\ Folder.
   And the previously mentioned .dll File from game\mod_tf\bin\ your mod\bin\ Folder.
   

The copying Process can be automated.
To do so, the Destination Folder in the $Compile .bat Files and the VPC Scripts need to be adjusted.
You may also choose to symlink these Files instead.

---

Steps to implement LUX into an existing Project.

1. Replace the materialsystem Folder in your src\ with the one from LUX.
2. Open materialsystem/stdshaders/ShadersBuildDirectories.bat
   There change targetdir and GAME_DIR so it matches your Mods Name and Path.
   If you have a custom .exe Filename, add it to the PROCESS_LIST here as well.
   PROCESS_LIST is only used for .vcs Reloading, so this is mostly optional.
3. Follow Steps from building LUXabove

NOTE1:
For the Shaders Project the .vpc Files are contained within stdshaders.
LUX provides the .vpc Scripts for both SDK2013SP, old SDK2013MP & the TF2SDK.
This means no Changes are necessary to the VPC Scripts to have it in your Solution.
If at some Point you have decided to change the Names of your Shader VPC Scripts,
you will have to modify the stdshader ones to account for that!

NOTE2:
Keeping some kind of commit-history between old and new Shaders is basically impossible.
Due to how LUX was made & designed, all old Shader Files are just gone, nuked, kablamo.
They may also be relocated, flipped upside down or renamed.
It is recommended you nuke materialsystem in it's entirety, commit it and then push LUX as a secondary commit.

Technical

For developing with LUX either as a Programmer, Artist or both see also:

• LUX Shader Wiki
  
• LUX replaced Shaders Table
  
• Debugging Shaders
  
• Writing new Shaders on LUX
  

Additional Resources

• Vanilla vbsp.exe does not recognize custom Shaders.
  This causes vrad.exe to not compile Lightmaps for custom Shaders.
  This is fixed in Forks like Mapbase and vbsp++.
• For Parallax corrected Cubemaps, vbsp.exe must be modified.
  See Parallax corrected Cubemaps changes for VBSP from Mapbase.

• Creating Shaders in the Source SDK 2013
• LUX Valve Developer Wiki Page

Contact

• Join the LUX Discord Server

Legal

Any Game or Modification that incorporates LUX or any Portion of its Codebase is required to include and redistribute the thirdpartylegalnotice.txt File.

---

Contributing

Thank you for your interest in LUX!
LUX is open to Contributions via the Pull-Request System.
By submitting a Pull-Request, you agree to comply with the SOURCE 1 SDK LICENSE.
Before making any Contribution, read the License Section.

Proposed Contributions that violate the Terms of the SOURCE 1 SDK LICENSE or the STEAM SUBSCRIBER AGREEMENT will not be accepted.
This includes, but is not limited to:

• Using leaked Code.
  
• Unauthorized use of Code.
  
• Reverse-engineered Code.
  

If your Contribution includes third-party Code, you must provide Attribution in accordance with that Code's License.
If possible the use of third-party Code should be avoided altogether.

---

Credits

Contributors refers to all Individuals or Entities that have submitted Code, Documentation, or other Materials to the LUX Project, during its Creation, either directly or indirectly.
Each Contributors work is provided under the same License Terms as the LUX Project itself.
Contributors are not legally liable or responsible for any Consequences, Damages, or Issues arising from the use, modification, or distribution of the LUX Codebase.
Some LUX Contributors have chosen to remain anonymous; They are not listed below.
If your contribution to the Project is not listed below, don't hesitate to get in contact.

Major Contributors

• ShiroDkxtro2: Creator of LUX.
• Trico Everfire: Tools, Research.
• Unusuario2 : GitHub README, Wiki, Shader Descriptions, and the ConCommand GitHub Wiki Dumper.
• Azzy: C++ Contributions.
• InevitablyDivinity: C++ Contributions, Linux Testing and general Source Engine-related Support.
• Kerim 'Nbc66' Čamdžić: C++ Contributions, Github Setup.
• Zeldaboy14: Tester on SDK2013SP and SDK2013MP and TF2SDK.
• Fortress Connected: Testing Maps from various Source Branches.
• Team Fortress 2 Classified: Critical Role in Testing.

Minor Contributors

• MrFunreal: Provided their Infected Shader Documentation and Suggestions for LUX ($BlendModulateTransparency, $FlipNormal for the Refract Shader).
• MrKleiner: Tools & Research.
• Krispy: Tester on SDK2013MP before the TF2SDK.
• [Jay]: Tester.
• URAKOLOUY5 ( Den Urakolouy ): Tester.
• Dana Cief: Materials used in Testing.
• .HAL9000.: $SSBump + $Detail References from Portal 2
• Polydot: Tester.
• Hexadot: Tester.

---

Third Party Code

LUX uses Third-Party-Code, those are listed below.
For more Details see thirdpartylegalnotices.txt

• Mapbase
• Alien Swarm: Reactive Drop

---

License

The LUX Codebase is licensed under the SOURCE 1 SDK LICENSE, which can be found in the LICENSE File at the root of this Repository.
Proper Attribution must be included when using or redistributing any Part of the Codebase.
The required Attribution is provided in thirdpartylegalnotices.txt, any additional Credits are always appreciated.

---