Updated Shader Changes (markdown)

Blixibon 2020-12-07 11:26:58 -06:00
parent f58afe49c0
commit 763c1f7189

@ -1,20 +1,22 @@
**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.
As part of some of the new features covered in [Graphical Changes](Graphical-Changes), Mapbase changes common shaders used by most materials.
(todo: talk about mods that have already changed shaders)
Normally, changing Source's shaders requires *a lot* of time, effort, and planning. Mapbase changes the shaders for many reasons, but part of it is to make common or easy changes accessible to users who wouldn't know how to implement them.
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.
Even though Mapbase handles most of the heavy lifting, **there is a steep and demanding caveat of modifying existing shaders which Mapbase users must know if they're using custom materials.**
# The Shader Caveat (IMPORTANT)
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 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. New shaders can be created using code *from* existing shaders, but existing shaders cannot be overwritten in the engine. This means things cannot be added to the existing `LightmappedGeneric`, but an identical shader called `SDK_LightmappedGeneric` could be created with its own changes. This is how Mapbase modifies Source's 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.**
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, **all materials must be changed 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](https://www.moddb.com/mods/mapbase/downloads/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.
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](https://www.moddb.com/mods/mapbase/downloads/mapbase-multi-tool) can automatically change all of the materials in a directory to the new shaders.** 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.
@ -48,72 +50,13 @@ Here's a list of vanilla Source shaders which Mapbase has custom `SDK_` counterp
---
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.
The majority of Mapbase's large-scale shader changes come from other projects or are based off of other versions of the engine. They're covered on the [Graphical Changes](Graphical-Changes) article.
---
## "Third Party" shader changes
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.
---
### Insolence/Alien Swarm/C17:EP1/G-String/VDC projected textures
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](Projected-textures).
<p align="left">
<img src="https://i.imgur.com/eI3RZs0.png" width="640"/>
</p>
---
### Radial fog
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.
<p align="left">
<img src="https://i.imgur.com/bOC9iZu.png" width="512"/>
</p>
Using white fog in the example picture was probably a bad idea.
---
### C17:EP1's phong on LightmappedGeneric
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](https://www.moddb.com/mods/city-17-episode-1).
(todo: also figure out what it looks like with an exponent mask for an in-Mapbase screenshot)
---
### Parallax Corrected Cubemaps
<p align="left">
<img src="https://media.moddb.com/images/articles/1/276/275123/auto/mapbase_demo030123.jpg" width="512"/>
</p>
Mapbase uses an implementaton of parallax corrected cubemaps [open-sourced on the VDC](https://developer.valvesoftware.com/wiki/Parallax_Corrected_Cubemaps). It's best-known from [this video](https://www.youtube.com/watch?v=ZH6s1hbwoQQ).
---
### Tree sway
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.
---
---
## Mapbase's own shader changes
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.
However, there's also a few other minor shader fixes covered below which originated from Mapbase itself.
---
### $blendmodulatetexture fixes
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.
Mapbase fixes $blendmodulatetexture not appearing under a flashlight, not working with transforms, and lets it show up in Hammer. It also uses the Alien Swarm SDK's version of the shader code.
[You can find the VDC article here.](https://developer.valvesoftware.com/wiki/$blendmodulatetexture)