Shader Changes
Shaders are used for rendering a scene on a user's GPU. The Source SDK comes with Source's shaders and allows modders to modify or add shaders to the engine.
Mapbase modifies Source's shaders in various ways, but most of these changes are just supposed to fix certain issues, add new capabilities, or make things easier to do.
(todo: talk about mods that have already changed shaders)
Before we go into more detail about these changes, there is a steep and demanding caveat of modifying existing shaders and that caveat needs to be made as clear as possible, especially how Mapbase gets past this caveat.
The Source SDK comes with the original shader source code and files which you could compile yourself, but Source doesn't actually allow modders to change existing shaders for security reasons. You can create new shaders with code from existing shaders, but you can't actually modify existing shaders in the engine. This means you can't add things to the existing LightmappedGeneric, but you can create an identical shader called SDK_LightmappedGeneric with your own changes. This is how Mapbase modifies the shaders. It uses custom SDK_ versions of the original shaders.
The problem is that materials still using the original shaders won't use Mapbase's shader changes, so in order to take advantage of these changes, you must change all of your materials to use the custom shaders.
Some mods go for things like an automatic passthrough system, which means all materials are changed to the new shaders without requiring the modificaton of any VMT files. This is useful for when you can't easily change every VMT that could be used in-game, e.g. when there's tons of VMTs embedded in tons of MP maps, but that has problems like material proxies being lost or decals not working with it. It also increases loading times.
For Mapbase, we instead opted for renaming all of the shaders in the VMTs themselves, which is the most basic and tedious solution, but the end result is much more efficient than the alternative. This isn't really too much of a problem, as these are just the plain-text VMTs, not the actual texture VTFs. Mapbase also comes with converted versions of all of Half-Life 2/EP1/EP2's VMTs, neatly packed in VPKs and staying at only about 2-3 MB total, so you'd only have to worry about this if you're adding custom materials or mounting materials from another game/mod. If you are using custom materials or mounting materials from another game/mod, the Mapbase Multi-Tool can automatically change all of the materials in a directory to the new shaders. In one trial, the mod version of Black Mesa: Source's 3,974 VMTs were converted to the new shaders in 1 minute and 58 seconds. It's recommended that you pack converted VMTs into a VPK file.
You could technically get away with using the original shaders if you don't need Mapbase's shader changes, as there's nothing inherently wrong with them, but they wouldn't look right if they're used alongside modded shaders because features like radial fog and projected texture changes would make their differences visible.
The only real outright requirement related to new shaders is that rope materials must use the SDK_Cable shader due to some other code changes that make the original Cable unusable.
Here's a list of vanilla Source shaders which Mapbase has custom SDK_ counterparts for:
LightmappedGenericVertexLitGenericUnlitGenericWorldVertexTransitionWaterSpriteRefractLightmappedReflectiveWorldTwoTextureBlendEyeRefractEyesEyeGlintTeethCableDepthWriteDecalModulateUnlitTwoTextureMonitorScreenShatteredGlass
The majority of Mapbase's large-scale shader changes come from other projects or are based off of other versions of the engine, so they've been split into two categories for changes made by other people and changes made specifically for Mapbase.
Other people's work from other people's projects that have been gathered into Mapbase.
Due to the nature of how these were implemented and how I didn't trust myself to change these things at the time, these changes are not nested in #ifdef MAPBASE preprocessors. You could see the differences in the DLL code through Git, but you'll have to do some text comparisons yourself on the FXC files.
The gnarliest Frankenstein of them all, Mapbase uses a combination of Alien Swarm, City 17: Episode One, and G-String projected texture changes obtained from Insolence's repository, as well as a few relevant VDC fixes. You can find more information on the dedicated article.
Mapbase uses Half-Life 2: Downfall's implementation of radial fog from the Alien Swarm SDK.
Radial fog first came to Valve's games through Left 4 Dead. Half-Life 2 still uses "planar" fog, which is calculated as a plane and changes as you rotate the camera. You could often see past it by rotating the camera and looking at the edge of your screen.
HL2: Downfall implements radial fog in Source 2013, which Mapbase uses and also extends to other shaders. This means fog is calculated radially and doesn't change as you rotate the camera, unlike planar fog.
Using white fog in the example picture was probably a bad idea.
Mapbase uses City 17: Episode One's LightmappedGeneric/WorldVertexTransition phong, implemented from Insolence's repository.
This was ported with the projected texture changes when Mapbase gleaned shader stuff from the Insolence repo, mostly because it was more difficult to not port them than it was to just avoid it. There was also some mild demand for them. Again, even though I got this from the Insolence repo, the code was almost entirely from City 17: Episode One and you could find more information on their ModDB page.
(todo: also figure out what it looks like with an exponent mask for an in-Mapbase screenshot)
Mapbase uses an implementaton of parallax corrected cubemaps open-sourced on the VDC. It's best-known from this video.
Mapbase uses Half-Life 2: Downfall's implementation of $treeSway from the Alien Swarm SDK.
Using this implementation as a base, Mapbase adds $treeSwayStatic and an entirely new $treeSwayStaticValues command to control static wind values. There's also a tree sway scale on env_wind, which is vital for when there's multiple env_wind entities in a map.
Shader changes created specifically for Mapbase, mostly by Blixibon.
The DLL code actually does have these changes nested in #ifdef MAPBASE, unlike the "Third Party" changes.
Mapbase fixes $blendmodulatetexture not appearing under a flashlight, not working with transforms, and lets it show up in Hammer. It also uses Alien Swarm's version of the shader code.
You can find the VDC article here.
Mapbase ports this parameter from Alien Swarm, which allows $phong to be used without $halflambert being forced enabled.
You can find the VDC article for $phong here, which lists $phongdisablehalflambert.
Mapbase adds $basetexturetransform2 to the DX9 version of the shader.
The issue was that $basetexturetransform2 actually only existed in the DirectX 8 version of the shader, simply not appearing in the DirectX 9 version. It's a strange anomaly and it's hard to decide whether Valve didn't think it was worth the trouble or literally just forgot. There's definitely a FIXME or two related to it.
Before this, $basetexture2 followed the original $basetexturetransform in DX9, so this only functions if you declare $basetexturetransform2 first:
$basetexturetransform2 "center .5 .5 scale 1 1 rotate 0 translate 0 0"
It doesn't work with $seamless_scale or the C17:EP1 brush phong.