Custom Postprocessing Shaders - in devbuilds now

[Rachael]

This is just basic right now. We do plan to implement passing uniforms to the shader - both from CVars and from ZScript.

The latest devbuild of QZDoom (as of this post) has them.

To use:

Code: Select all

hardwareshader postprocess scene
{
	Shader "shaders/custom/retroshader.fp" 330
	Texture "sometexture"
}

Note that texture binding does not currently work. (We're working on that) So don't expect textures to work at this time.

The syntax is exclusively in gldefs.txt and is as follows:
hardwareshader postprocess <scene/screen>
{
Shader "<link to shader file in your pk3>" <glsl version (should be 330)>
[Texture "<link to texture file in your pk3>"]
}

Texture (When it's implemented) is optional.

"Scene" is before 2D draws, and only applies to the game view. "Screen" is after 2D draws, and will apply to the UI too.

This is not yet final, syntax may change.

CVAR: gl_custompost <true/false> (turns this system off completely)
Multiple shaders do stack.

Attached is a couple of proofs of concept showing how this works and the proper way to do it. One is an updated version of torridgristle's RetroShader (sorry, needed something to test/develop this feature on).

Not a lot of error checking yet - need people to break this to see how we can improve on it.

Yes - this will currently cause GZDoom to error out. (Sorry) You have to use QZDoom to use these.

[Nash]

Oh shiieeeeeeeeetttttttttttt.

Gonna try port steal copypasta-i-have-no-idea-what-im-doing some shaders from http://www.shadertoy.com/ and see what happens.

Thank you dpJudas and Rachael! You'll probably start seeing a lot more shader questions from me from now on. ;D

EDIT: Can we get some basic info on what types are available to work with, and maybe what would be available in future?

EDIT 2: Will some of the built-in PP shaders be ported to be externally editable? Like perhaps some mods would like to tweak the built-in SSAO or lens distortion algorithms, perhaps.

[Rachael]

Once we start making the system more robust, sure. We could certainly export some of the internal PP shaders. But I think that's a way's off a bit before that happens.

Mostly, the person who knows the most about the engine seems to be the least interested in this stuff, which is why we had to do this in a fork instead of on the main port.

Right now, the main goal is to get it into user's hands and let them break it. We want to see the different ways it breaks, empirically, with what the intentions are behind the work that causes it to break, and work around that, and build the system on top of that.

[Xaser]

Note that texture binding does not currently work. (We're working on that) So don't expect textures to work at this time.

Just to clarify: do you mean 'texture' in the GL sense (i.e. "any graphical resource", as opposed to Doom's definition)?

[dpJudas]

The current code attempts to bind a Doom texture as an OpenGL texture so that the shader can use it as data. It is not working right now, though.

The exact syntax is still not finalized, but imagine something along these lines:

Code: Select all

hardwareshader postprocess screen  <--- screen tells it to run this shader at the 'screen' stage in the post process pipeline
{
    Name "myshader"   <-- give this shader a name to be used via ZScript
    Shader "myshader.fp" 330     <-- this tells it to load myshader.fp if the GLSL version supported by the hardware is 3.30 or newer
    Uniform2DSampler "MySampler" "sometexture"   <-- bind the Doom "sometexture" resource to the sampler named MySampler in the program
    UniformFloat "MyFloatValue" 45.0   <-- bind MyFloatValue so that its value can be specified from ZScript, the value defaults to 45.0
}

The general idea here is that ZScript controls when the shader will be shown and also how it gets its input.

[Nash]

That makes sense. I was just thinking about an underwater view warping shader, and how to interface it with ZScript so that the shader will only be enabled when the player is actually under water. I'm guessing we will eventually be able to make a (?) uniform bool and just make the ZScript enable or disable that bool in the shader.

[Rachael]

It's going to be tricky to expose shared objects (such as Uniforms) between GLSL and ZScript, but I know it can be done. The main tricky part for me here is fudging the ZScript compiler to actually allow this.

Unfortunately, when shaders aren't running, that'll inevitably cause ZScript scripts to fail compile. That will also have to be handled in a special way, too.

The best thing to do might be to allow modders to give their shaders class names, and expose them to ZScript that way, and allow their uniforms to be modified in there.

[Graf Zahl]

It's going to be tricky to expose shared objects (such as Uniforms) between GLSL and ZScript, but I know it can be done. The main tricky part for me here is fudging the ZScript compiler to actually allow this.

The really tricky part here will be to implement it in a way that's compatible with Vulkan which does not have loose uniforms - only uniform buffers.

[dpJudas]

I suppose we can get around that by requiring the uniforms to be placed in an uniform block. That will bump the minimum requirement to be OpenGL 3.3 or something along those lines, but that's already the minimum for the modern GL path anyway.

It will introduce the issue of knowing the memory layout of the uniform block. For OpenGL that can be queried afaik - but I'm not sure how that works for Vulkan.

@Rachael: I'm not sure I'd expose the uniforms as actual variables (or an uniform block as a struct), although it certainly would be a lot more fancy if it was done that way. In any case, I'd make it so that the ZScript part would work regardless of whether the shader was compiled or not. IMO it should be the responsibility of the ZScript code to react gracefully to the case where changing the uniform variables simply does nothing (as the shader isn't being run).

Edit: knowing the layout of the block could be done by making ZDoom generate the uniform block declaration and not the shader itself.

[Rachael]

New devbuild up - supports basic uniforms - still have to put in "timer" support (I do plan to do that, still)

Here's a basic example for how to do uniforms.

[Nash]

Question: to do water plane refractions (a water flat that distorts everything behind it, like old Doom Legacy)... and perhaps water reflection. Are these considered PP effects, or are they something else entirely?

[I am currently still getting a feel for the entire thing... I plan to show some cool stuff as soon as I know heads and tails of everything!]

[Rachael]

Those are definitely not PP effects and the only way that is possible in GZDoom is by hijacking the sector reflection code. From a coding point of view, it's a virtual portal that acts as a mirror - much like ye olde mirrors.

However, if you add in a second texture to the scene, what is possible to do is render the "mirror" to that texture, and then you can use shaders to distort the texture, itself, based on a ripple pattern. This is how water is done in at least the earliest versions of the Source engine (you actually can see 'hints' of that if you enable a few certain debug modes).

[Nash]

However, if you add in a second texture to the scene, what is possible to do is render the "mirror" to that texture, and then you can use shaders to distort the texture, itself, based on a ripple pattern. This is how water is done in at least the earliest versions of the Source engine (you actually can see 'hints' of that if you enable a few certain debug modes).

This was what I was thinking. I wonder if I could just take a copy of the current scene view, distort it then apply It back to the current texture.

I assume this not possible yet because texture's isn't done yet, and I also assume this isn't supposed to be applied as fullscreen PP, but rather on to a Doom texture itself (like what GZDoom is doing with the warp shader).

[Rachael]

I really do think you're going to need to get something closer to the Source engine method and actually render an alternate viewpoint. This can actually be done directly to a camera texture. Simply reversing the screen isn't going to get anything even remotely correct - and the problems with that method will become glaringly obvious very quickly.

That being said - you do not need texture uniforms to do that method, as problematic as it would be - you could define it directly in the shader, itself, or even just use the screen texture directly.

[Graf Zahl]

And let's not forget that reflective floors and ceilings are one of the most expensive effects of all. Nash, it seems you are again getting carried away by impossible prospects.
And repurposing the originally rendered scene is not going to work because the perspective is all wrong.