Custom Postprocessing Shaders - in devbuilds now

Archive of the old editing forum
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Custom Postprocessing Shaders - in devbuilds now

Post by 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.
You do not have the required permissions to view the files attached to this post.
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by Nash »

Oh shiieeeeeeeeetttttttttttt. :mrgreen:

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

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.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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.
User avatar
Xaser
 
 
Posts: 10773
Joined: Sun Jul 20, 2003 12:15 pm

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by Xaser »

Rachael wrote: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
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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.
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by Graf Zahl »

Rachael wrote: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
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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.
You do not have the required permissions to view the files attached to this post.
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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!]
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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).
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by Nash »

Rachael wrote: 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).
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [QZDoom] Custom Postprocessing Shaders - in devbuilds no

Post by 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.

Return to “Editing (Archive)”