User:Cvoxalury/Sandbox: Difference between revisions
No edit summary |
(Drafting up $additive article) |
||
Line 1: | Line 1: | ||
==$additive== | |||
{{this is a|shader parameter|name=$additive}} | |||
It specifies that the material should be rendered additively; that is, its colour values will be added to underlying pixels. This means, among other things, that the material will always brighten the world behind it. This is useful for effects like volumetric dust, light sprites, etc. | |||
The amount of brightening depends on the brightness of the texture. A fully black texture will become invisible, which can be a useful exploit (see below). | |||
This does work together with $color and $color2, allowing to control the strength of the additive blending, and change it with Proxies. | |||
$additive is supported by almost every shader (todo - double check which do and don't work with it, like water or refract), and does not require the texture to have an alpha channel. It also doesn't share the numerous caveats of $translucent and $alphatest, such as being mutually exclusive with $selfillum, or other shader parameters that make use of the alpha channel, for that matter. (todo - double check which do and don't work with it, like bumpmap) | |||
===Special uses=== | |||
Because $additive works by adding colour values, pixels that have 0 colour (that is, RGB 0 0 0 - black) become invisible with it. However, this does not necessarily prevent other shader paramters from working, such as $detail, $selfillum, $emissiveblend, $envmap. This trick can be quite useful for creating overlaying effects, very clear but reflective glass, or even making translucent and/or glowing cables. In a way, this also allows for having a kind of masked application. | |||
== Document the 'tile' type of [[func_breakable_surf]] == | == Document the 'tile' type of [[func_breakable_surf]] == | ||
Document its hardcoded pre-requesites and differences. Won't do much good until a leak-free pack of tile crack textures is made | Document its hardcoded pre-requesites and differences. Won't do much good until a leak-free pack of tile crack textures is made |
Latest revision as of 15:47, 14 January 2025
$additive
$additive
is a material shader parameter available in all Source games.
It specifies that the material should be rendered additively; that is, its colour values will be added to underlying pixels. This means, among other things, that the material will always brighten the world behind it. This is useful for effects like volumetric dust, light sprites, etc.
The amount of brightening depends on the brightness of the texture. A fully black texture will become invisible, which can be a useful exploit (see below).
This does work together with $color and $color2, allowing to control the strength of the additive blending, and change it with Proxies.
$additive is supported by almost every shader (todo - double check which do and don't work with it, like water or refract), and does not require the texture to have an alpha channel. It also doesn't share the numerous caveats of $translucent and $alphatest, such as being mutually exclusive with $selfillum, or other shader parameters that make use of the alpha channel, for that matter. (todo - double check which do and don't work with it, like bumpmap)
Special uses
Because $additive works by adding colour values, pixels that have 0 colour (that is, RGB 0 0 0 - black) become invisible with it. However, this does not necessarily prevent other shader paramters from working, such as $detail, $selfillum, $emissiveblend, $envmap. This trick can be quite useful for creating overlaying effects, very clear but reflective glass, or even making translucent and/or glowing cables. In a way, this also allows for having a kind of masked application.
Document the 'tile' type of func_breakable_surf
Document its hardcoded pre-requesites and differences. Won't do much good until a leak-free pack of tile crack textures is made
draft:
- 1) the vmt of the undamaged tile, which, is simply enough, the green tiles here. LightmappedGeneric
- 2) the vmt of the damaged tile, which is a ShatteredGlass, with a proxy and $detail, same exact deal as the glass material, just tile instead. This vmt is referenced in 1) as $crackmaterial
- 3) a bunch of hardcoded mats
"models/brokentile/tilebroken_03a";
"models/brokentile/tilebroken_03b";
"models/brokentile/tilebroken_03c";
"models/brokentile/tilebroken_03d";
"models/brokentile/tilebroken_02a";
"models/brokentile/tilebroken_02b";
"models/brokentile/tilebroken_02c";
"models/brokentile/tilebroken_02d";
"models/brokentile/tilebroken_01a";
"models/brokentile/tilebroken_01b);
"models/brokentile/tilebroken_01c";
"models/brokentile/tilebroken_01d";
These had to be copied from the 2003 leak. But they're simple small cracked tiles to form the edges; the BrokenGlass folder can be used as reference in making substitutions for them.
The 3) is the biggest obstacle but other than it, it doesn't need much.
It can even very feasibly be un-hardcoded in a mod and turned into a setting of the entity.Sky Lists
Rework of the sky list template so it's more compact and easier to read.
HL2