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).
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:
The shader.jpg
Here is what I'd like to get (I put a thin opaque 3D floor above the surface with the shader texture applied):
Desired result.jpg
Here is the enivornment map texture:
EnvironmentMap.jpg
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:
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.
Talon1024 wrote: ↑Mon Sep 09, 2019 10:40 pm
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:
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.
Spoiler:
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.
Spoiler:
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.
Spoiler:
The shader code itself, which I think I'll post in the shaders section later once I think it's fully ready.
/**
* 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;
}
Last edited by illYay1337 on Sat Nov 19, 2022 12:31 pm, edited 1 time in total.
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;
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?
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.
Caligari87 wrote: ↑Thu Apr 13, 2023 7:57 am
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.
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