Custom Postprocessing Shaders - in devbuilds now

[ibm5155]

Is FOG a PP thing? if yes could I create a new type of fog with that? (I have a working code but it replaces the ehm software fog or doom fog)

At any case here's the code:

Code: Select all

//===========================================================================
//
// Doom lighting equation exactly as calculated by zdoom.
//
//===========================================================================
float R_DoomLightingEquation(float light)
{
	float TotalLight = light * 255.0;

	//Spooky house Light Equation
	float lightscale = 1.0;
	//light/33 should be 4 whe light is 130
	float MaxFullLightDist = (TotalLight/33) * TotalLight;
	float tmp=0;
	if(TotalLight > 0){//sector light is zero so there'll be no light
		if(TotalLight == 255){ //if the sector is full light, it'll always be full light
			lightscale = 0;
		}
		else if(pixelpos.w < MaxFullLightDist){ // if the pixel is before the full bright limit, make this pixel full bright
			tmp = min(pixelpos.w / 10.0, 64.0 + MaxFullLightDist + (TotalLight/10));
			tmp = (tmp / (64.0 + MaxFullLightDist  + (TotalLight/10) ) )* 10 ;
//			tmp = int(tmp);
			lightscale = clamp(tmp, 0 ,1.0);

//			lightscale = 0;
		}
		else{			
			tmp = min(pixelpos.w / 10.0, 64.0 + MaxFullLightDist + (TotalLight/10));
			tmp = (tmp / (64.0 + MaxFullLightDist  + (TotalLight/10) ) )* 10 ;
//			tmp = int(tmp);
			lightscale = clamp(tmp, 0 ,1.0);
		}

	//	lightscale = clamp((  min(pixelpos.w  * L , 76500.0)) / 76500.0, 0.0, 1.0);
	}
	return lightscale;
}

[Gutawer]

Something like fog would require access to the depth buffer, which tells you how far away each pixel is, so no, it's not possible right now with these postprocessing shaders.

[Nash]

Changing that sounds like more than post processing, you are looking at overriding the main rendering and shading/lighting pipeline...

[Rachael]

I actually would not have an issue for allowing a custom fog shader. Obviously his mod depends on that, and so he'll be stuck with an old GZDoom version until official support is added. But even so - I think such a thing should be limited. There's no telling what can happen to the rendering pipeline - and while PP shaders were relatively safe to add, doing things that happen more or less in the middle of everything else is not. A shader like this will require access to the depth buffer.

It may be possible to simply send the depth buffer to the custom PP shader system though - (dpJudas would know more than I would, at this point, about that) - that would easily make it possible to completely customize the fog.

[dpJudas]

I don't think it is a good idea to allow custom fog shaders. This part of the pipeline is not as clearly defined as the PP part.

About the depth buffer: due to the way portals are implemented the depth buffer does not have the complete information required when the scene finishes rendering. The SSAO shader runs in between opaque and translucent rendering because of this. I don't think algorithms that requires depth information will work without further cooperation from the engine.

[Rachael]

Is it possible to render a post-portal depth buffer as a single texture and simply putting all SSAO and fog effects onto that, instead?

[dpJudas]

There's two problems here. First is that portals modify the depth buffer (it seals them off after rendering by filling it with a "wall"). The second is that translucent objects reads from the depth buffer, but may or may not draw to it.

The scene render code could in theory copy the depth values from before something was sealed and add them back at the very end, but this is rather expensive. It also wouldn't work for something like a SSAO pass as it needs to run in between opaque and translucent.

What ibm5155 is doing here is completely redefining what a light level is and how it is shaded. I don't think it is within the scope of a postprocessing shaders feature.

[Rachael]

I agree. Very well, then.

By the way I added a new "enabled" flag for the GLDEFS part of the shaders. It should not be required to use ZScript to turn these on.

[Tormentor667]

About the shader thingie now, when is this going to be added to GZDoom as well?

[Rachael]

Right now there are no plans. There have been no discussions about adding it. In fact, Graf has been previously opposed to it because it would hold back Vulkan support (to which I've already proven there's a special shader compiler available that will compile GLSL into Vulkan-compliant bytecode).

If Graf wants it, it's there. I think dpJudas was even kind enough to maintain a GZDoom-specific branch for it.

Besides, the independence gives us the ability to perfect and add new features to the whole thing before it (likely, eventually) does get merged.

(p.s. as a side note, much as I hate "splitting the ports" again, GZDoom is not my port and Graf does not readily approve things like this. I am not going to force him to take this if he doesn't want it. I will continue to help maintain GZDoom from a bug-fixing standpoint as I already have the past few months, but new features such as this will be handled differently from now on - for this reason, QZDoom exists for the exact same reason as it did before, it's completely up to Graf how he wants to handle this branching as it is now)

[ibm5155]

so, with vulkan we're going to have a "Vulkan options" "Opengl options" and "Software options" menu?
plus, is there any test case with vulkan for a doom engine like software that shows it's indeed gonna have a huge performance increase?
the only experiments that I saw a huge performance increase were only synthetic benchmarks to specific tasks (like showing alot of cubes on screen as fast as it can).

Maybe an software simulating the way the gzdoom engine Works in a simple (without any kind of decorate/zscript/acs,sounds...) way would be nice to have before putting tons of code before even knowing if it's gonna increase like 10% of performance.

[dpJudas]

to which I've already proven there's a special shader compiler available that will compile GLSL into Vulkan-compliant bytecode

That wasn't his complaint. It was that uniforms required an uniform block with the open source GLSL compiler (no default uniform block like D3D11 has). However, I solved that by making the C++ code declare the uniforms.

[Wiw]

Is a 32X-like shader possible?

[Major Cooke]

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.

This had me thinking of update-able vertices like what ZZYZX was working upon. I can only imagine the horror such an effect could have, if it were even doable at all.

[Major Cooke]

Can this get a small sticky for the time being, please? I'm working on documenting this stuff in the wiki but having trouble deciding on where it should go, unless you two want to hangle it yourself?

Also is this still currently just QZDoom only or is the merge with GZDoom meaning it'll work using its renderer too? That'll determine if I need to make a QZDoom only tag or not, if it hasn't been made yet.