Shader Help Thread

[Darkcrafter]

I would like to make at least a semidecent fake environment map based shader. I already got one working in GZDoom but I'd like to mix that shader result to a texture applied so the effect of "reflection" would have an effect amount (opacity).

Here is the shader by Marisa:

Code: Select all

vec4 Process(vec4 color)
{
    vec3 eyedir = normalize(uCameraPos.xyz - pixelpos.xyz);
    vec3 norm = reflect(eyedir, normalize(vWorldNormal.xyz));
    return getTexel(norm.xz * 0.5) * color ;
}

It basicaly takes a texture (environment map) and applies it over a surface so it renders in a sky manner.
Here is what it looks like:

Here is what I'd like to get (I put a thin opaque 3D floor above the surface with the shader texture applied):

Here is the enivornment map texture:

So what I'd like to get is to being able to define a particular environment map texture in GLDEFS per texture so the shader would kind of process both textures at once, like that:

Code: Select all

material texture "FLOOR7_2"
{
	shader "shaders/EnvMapRefl_Marisa.fp"
        reflectionmap "textures/reflectionmaps/environmentmap1.jpg"
        opacity 0.5
}

[illYay1337]

I agree. This needs to be better documented for sure. I had to peice info together from looking at other shaders. There are keywords that aren’t documented.

On the [wiki]GLDEFS[/wiki] wiki page, it says:

The following uniform variables are always available to your shaders:

int fogenabled
vec4 fogcolor
vec3 dlightcolor
vec3 camerapos
float desaturation_factor
vec4 topglowcolor
vec4 bottomglowcolor
int texturemode
sampler2D tex
float timer

If you wish to use the timer uniform, you must define it yourself at the top of your shader file.

If the DYNLIGHT define is defined, the following uniform variables available:

ivec3 lightrange
vec4 lights[256]

Only if MAXLIGHTS128 is not defined

vec4 lights[128]

Only if MAXLIGHTS128 is defined

The following varying variables are always available to your shaders:

float lightlevel
vec2 glowdist
vec4 pixelpos
vec4 fogparm

Is this list up to date? And where in the GZDoom source code are these values defined and passed to user shaders for textures?

[illYay1337]

My account works again so I'm able to post here. Made the original post here just now but I'm sure this is a better thread to ask questions. https://www.doomworld.com/forum/topic/1 ... m-shaders/

I normally consider myself somewhat of an expert with GLSL and computer graphics so I was able to piece together how to make a custom shader in GZDoom after poking around.

Basically I'm running into issues where surfaces that have a shader applied seem brighter and are lit differently than surfaces without shaders.

Here the walls that are not at 90 degree angles are really showing the effect. The darker walls are the non-shader version. The 90 degree walls on the right have no issues, which I'm guessing is because it's in the default shading mode on this map right now.

---

Here the surfaces with my shader are flat shaded instead of using sector lighting, which actually makes things look a bit uglier. Seems like we don't have access to the vertex shader and I'm not really sure how to even do smooth shading in Doom with normal geometry short of using a 3D model. I'd rather it actually used sector lighting so I just get the shader effect.

---

Also surfaces with a shader exhibit this pinprick effect, which is especially visible on slopes. It's easier to see against a solid color with a super simple shader that outputs red.

---

The shader code itself, which I think I'll post in the shaders section later once I think it's fully ready.

---

Code: Select all

/**
 * Shader that does triplanar mapping which should be great for natural terrain textures
 * The UVs are procedurally determined based on world coordinates so caves, mountains, etc automatically look good
 * This can be very useful for Doom where it's otherwise difficult or nearly impossible to align walls and flats
 * At the moment it's built to take the passed in texture and triplanar map it.
 *
 * Made with the help of this article: https://www.martinpalko.com/triplanar-mapping/#The%20Theory
 *
 * Future versions or variations might get more advanced, and you could make snowy mountains for example, by having top facing normals use a snow texture
 * 
 * Usage: Add to gldefs as explained here: https://zdoom.org/wiki/GLDEFS
 *
 * You can add either a worldScale define or uvScale define
 * By default it acts as if you passed worldScale 1.0
 * worldScale 1.0 will try to map the texture as closely to how doom would map it as possible in doom's world coordinates
 * Other values will multiply the scale
 *
 * uvScale won't take world scale into account and will just base UV's one to one with world position, so you may want very low values like .001 to look good.
 * uvScale is slightly more optimized since there's no division by texture size
 *
 * e.g.
 * material texture "textures/ogrodtex/OGRIDRST_triplanar.png"
 * {
 *   shader "shaders/triplanar.fp"
 *   define worldScale = 2
 * }
 */

Material ProcessMaterial()
{
    Material material;

    vec2 uvScaleActual =
#ifdef uvScale
        vec2(uvScale);
#else

#ifndef worldScale
#define worldScale 1.0
#endif
        //to sample the texture in "DooM" world units we divide by its size
        1.0 / textureSize(tex, 0) * worldScale;
#endif

    vec3 normals = normalize(vWorldNormal.xyz);
    vec3 blendWeights = abs(normals);
    
    // Z normal faces north/south
    // Y normal faces floor/ceiling or up/down
    // X normal faces east/west

    // Floor / Ceiling need to sample in the -v direction
    // Walls sample in the -v direction as well, but also flip u depending on facing direction to more roughly match doom's texture mapping

    vec2 northSouthUVs = pixelpos.xy * vec2(sign(-normals.z), -1.0) * uvScaleActual;
    vec2 floorCeilUVs = pixelpos.xz * vec2(1.0, -1.0) * uvScaleActual;
    vec2 eastWestUVs = pixelpos.zy * vec2(sign(normals.x), -1.0) * uvScaleActual;

    material.Base =
        // North / South
        getTexel(northSouthUVs) * blendWeights.z
        // Floor / Ceiling
        + getTexel(floorCeilUVs) * blendWeights.y
        // East / West
        + getTexel(eastWestUVs) * blendWeights.x;

    // In the future, if more textures are used for other material components, sample them in a similar way
    // Future versions can also sample a totally different texture for Floor, for example, to add snow or grass to tops of hills
    // You could also sample different textures based on elevation in world coordinates, so high peaks are snowy while low areas are grassy

    return material;
}

[illYay1337]

Ah it's actually hilarious what a mistake I made.  It was brighter because of a mistake in the triplanar shader not because the engine was making things brighter.



I tried regular solid colored textures and the same odd artifacts were visible for me.  The brightness came from this:

return
        // North / South
        getTexel(northSouthUVs) * blendWeights.z
        // Floor / Ceiling
        + getTexel(floorCeilUVs) * blendWeights.y
        // East / West
        + getTexel(eastWestUVs) * blendWeights.x;

I was over brightening the pixels which happens with any angled surface but never with 90 degree surfaces.  BlendWeights came from a normalized vector, but the sum of the components wasn't 1.  I somehow forgot that a normalized vector is of length 1 but the sum of its components is not 1, which caused the 3 colors to blend incorrectly resulting in an overbrigthened pixel.

Had to add this earlier in the shader.

    // make it so the sum of all components is 1
    blendWeights /= blendWeights.x + blendWeights.y + blendWeights.z;

[DELTAtheDboi005]

Not sure if this is the right thread, but how would I go about making a shader that creates a ps1-style texture warp like metal gear solid or other games from that particular point in time?

[Caligari87]

What you're referring to is (I believe) affine texture mapping, and so far as I'm aware there's no way to accomplish it in GZDoom because mods don't have access to the vertex shader.

See this topic on PS1 rendering for some relevant discussion.

[DELTAtheDboi005]

What you're referring to is (I believe) affine texture mapping, and so far as I'm aware there's no way to accomplish it in GZDoom because mods don't have access to the vertex shader.

See this topic on PS1 rendering for some relevant discussion.

I think I came across that thread recently whilst researching how to do this and I pretty much came to the same conclusion as everyone else at the end of that thread. Bummer

[IstoleyourToast]

which version of glsl does gzdoom support? I have OpenGl 4.5 Gpu and want to make some shaders so should i learn glsl 3.30 or 4.50?

[Enjay]

Is there any way to have a shader work in the world view but not on the automap?

As has been noted by a few people, some shaders look good in world but may not look as good on the automap. So, I was wondering if there was any way to tell U/GZdoom "don't use this on the textured automap view" via GLDEFS, or in the shader definition itself or whatever.

[Enjay]

OK, after a lot of head-scratching, digging into the code and some help (thanks for trying dude), it seems that there is no reliable built-in way to tell a shader that the player is looking at the automap. Without that, there isn't a nice, robust way to tell the shader "do this in the game world, and that at the automap."

The closest I have managed to get is a double check.
if gradients are flat, there is a good chance I'm at the automap. However, looking at a flat straight-up, or straight-down in the game world creates the same basic effect and the shader disables itself in the fame view while doing that.
So, if I also have a depth check and if both the the gradients are flat and the depth is shallow, then I am almost certainly at the automap.

However, this feels a bit hacky. Also, even setting the values so that they are highly unlikely to occur in the game view still leaves the possibility that it could happen. So, if it does, the shader would simply disable in front of the players eyes - not desirable.

Anyway, I've opened a feature suggestion issue on GitHub to ask if a proper flag can be added that will allow a shader to check for certain whether the automap is active or not. https://github.com/UZDoom/UZDoom/issues/686