Custom Postprocessing Shaders - in devbuilds now

[Rachael]

Which is exactly why the other viewpoint is needed. First of all - the view pitch translation needs to actually be reversed - and secondly the eye must be placed deep into the ground (actually, exactly the height of the viewpoint from above the ground). There is no way it will look even remotely correct if you do not follow this very basic tenant of reflection.

After that, then you may reverse the Y-axis of the texture and flip it upside down. Without even looking at GZDoom's reflective floor code, I would wager to guess this is very close to how it's already being done, anyway.

[dpJudas]

I think the postprocessing shaders are mainly useful for stuff like powerup effects (i.e. invulnerability), underwater effects and damage effects. The sort of thing that is short lasting, but where drawing it with player sprites does not get the job done for one reason or another.

Stuff that requires complex pipeline setups are a bit problematic and are probably not going to get supported - at least not in an initial version. It requires a system that is flexible and not locking the GL renderer in its current implementation. A water plane shader is a good example of something that needs support directly by the engine, even if they technically are screen space shaders.

[Rachael]

Well GZDoom has reflective floor code, already. If that's placed into a render buffer instead of a stencil, the resulting texture could be used for the purpose Nash proposes. Of course, it would require setting up a reflective floor on the map itself, but at least then you're free to do what you want with the shader that uses it.

At any rate, I believe you're right, dpJudas, in that at the very least, all of this is beyond the scope of a screen shader.

[dpJudas]

That's what I meant by direct support by the engine. The scene passes needs to build up input for the shader to consume, which I'd say is a bit out of scope for simple custom postprocessing shaders. Right now the scene render code doesn't have any deeper support for such stuff than "is the SSAO pass active? use gbuffers, otherwise not" without any general strategy to how gbuffers and other outputs should be handled.

[Graf Zahl]

Reflective floors are a lot more tricky. If you try to warp the renderbuffer that gets created it may expose holes because if it tries to simulate a reflective liquid it obviously also needs to be aware of that liquid's EDGES. It's not as simple as grabbing the entire scene, doing a bit of messing around and render it back. That will surely look like garbage.

[Rachael]

Yeah, I have thought about that. For that, I think you could just render the normal scene into a stencil on the same texture, and it won't look quite as bad. Of course - up goes the processing time on the scene.

[Graf Zahl]

The main issue would still be to render a physically correct (or at least sufficiently correct looking) reflection - that math isn't fun. I have no idea how modern games handle that.

[dpJudas]

I added a new insertion point for the postprocess shaders called 'beforebloom' in case the mod wants it to run before the built-in post process filters are run.

Should the ZScript integration be play or ui? Right now they are marked as play, but that means the uniforms can only be updated at 35 hz.

[Nash]

Will the scope determine what kinds of effects would be possible or blocked, eg - what if I wanted to write a shader that needs to query a position of something in the world (let's say a sun shader that wants to draw rays originating from the sun's position in world space).

[dpJudas]

Yes. If the scope is play then that position wouldn't take the interpolation and camera rotation into account that happens between game ticks. I probably should just change them to be ui to be on the safe side.

[dpJudas]

I've updated the API for this so that it should be Vulkan safe.

The GLDEFS syntax is now:

Code: Select all

hardwareshader postprocess scene
{
	Name "healthshader"
	Shader "healthshader.glsl" 330
	Uniform float saturation
	Uniform vec3 saturationColor
}

The ZScript API is now:

Code: Select all

struct Shader native
{
	native clearscope static void SetEnabled(PlayerInfo player, string shaderName, bool enable);
	native clearscope static void SetUniform1f(PlayerInfo player, string shaderName, string uniformName, float value);
	native clearscope static void SetUniform2f(PlayerInfo player, string shaderName, string uniformName, vector2 value);
	native clearscope static void SetUniform3f(PlayerInfo player, string shaderName, string uniformName, vector3 value);
	native clearscope static void SetUniform1i(PlayerInfo player, string shaderName, string uniformName, int value);
}

Used from ZScript it might look like this:

Code: Select all

Shader.SetEnabled(Player, "healthshader", true);
Shader.SetUniform1f(Player, "healthshader", "saturation", clamp(health / 50.0, 0.0, 1.0));
Shader.SetUniform3f(Player, "healthshader", "saturationColor", (1.5, 0.5, 0.5));

With a shader looking like this:

Code: Select all

void main()
{
	vec4 c = texture(InputTexture, TexCoord);
	c.rgb = mix(saturationColor * dot(c.rgb, vec3(0.3,0.56,0.14)), c.rgb, saturation);
	FragColor = c;
}

The attached file is a full example where it adds some global saturation whenever the health go below 50% or above 150%. Please note it won't work until the next dev build is ready.

[Nash]

Wheeee! Thanks so much for this. I know it looks like probably only 2 people are interested at the moment, but that's because GLSL itself is almost like black magic to most people here (heck, most people were intimidated by ZScript, even I took a few months before I jumped in :P), and speaking for myself, I'm finding it a bit of a struggle to fully understand GLSL currently.

I do have like a super super duper basic understanding, thanks to you explaining stuff to me in the menu blur thread, so that's a little helpful, but otherwise I'm still on my own here. :D

My efforts will most likely start with copy/pasting stuff from Shadertoy, tweaking it until it runs and hopefully learn something from all that.

Also many thanks for taking the time to put together example files, I took a look and this is SO MUCH more helpful than just a bunch of how to's in a forum thread.

[Gutawer]

I've already expressed my gratitude on this in the Discord, but agreed - thank you so much for your work here, to everyone involved. Once all of this stuff is finalised and I feel confident that nothing will change in the future and break anything I release, it'll be great to release my stupid Bioshock-esque Drunk-mechanic mod .

[dpJudas]

Thanks guys.

About changes: at the moment I kind of consider the current API final for a 1.0 version unless someone finds something wrong with it. I would like to give access to textures in a future iteration, but I'd rather have something basic that is correct than loads of features that could become a nightmare to support in the future.

[Marisa the Magician]

I know it looks like probably only 2 people are interested at the moment

Make that 3 people.