Implement rendering pipeline and post-processing

[x2048]

This PR implements rendering pipeline as described in #12411 Alternative B and a minimal post-processing shader on top of the pipeline.

Fixes #12411 and fixes #5446

To do

This PR is Ready for review

• Define base classes
• Implement simple rendering steps (3D and HUD)
• Implement RenderingCorePlain as a pipeline
• - Rendering to a TextureBuffer
• - Scaling as a pipeline step
• Implement Stereo modes
• - Anaglyph
• - Interlaced
• - Page flip removed because not supported by current Irrlicht version
• - Side by Side / Top Bottom / Cross eyed
• Handle window resizing in a generic way
• Implement shadow mapping as a pipeline step
• Implement post-processing as a pipeline step
• Implement common pipeline factory for 3D stage
  Merge undersampling with all 3d modes - postponed to a future PR
• Merge post-processing with all 3d modes
• Move tonemapping to postprocessing
• Optimize use of textures
• Fix spaces vs tabs
• Make it work on GLES2

How to test

• Choose your favorite stereo mode with or without shaders
• Start the game
• Everything must work correctly

[lhofhansl]

Tried. Everything seems to work as before.
@x2048 That's a lot of code to review. Anything you'd like to focus on?

[x2048]

@lhofhansl I'd love you feedback on the way pipelines are built, side-by-side would be a good example.
And the framework itself pipeline.h / pipeline.cpp may need a pair of eyes.

Thank you!

[x2048]

@lhofhansl I've made slight changes to the pipeline framework, removing duplicated code here and there.

[lhofhansl]

With the latest update I find different behavior:

1. the sun is no longer rendered
2. shadows are suddenly view angle dependent
3. entities are do not have shadows on them anymore

(I'm pretty sure this did not happen when I tested yesterday)

[x2048]

Hmm... I can't confirm. Sun and entity self-shadowing can be seen here:

Area where shadows are rendered is dependent on view angle and it may be noticed if you rotate head fast, when shadow_update_frames is 8 or 16.

[lhofhansl]

Hmm... Lemme test that again...

[lhofhansl]

Re-compiled everything. The sun is visible. My mistake.

But the other issues remain. What thew me off is that shadows seem to dependent on the aliasing setting. When aliasing is none, then entities self-shadow, but blocks no longer have shadows. At other aliasing settings blocks have shadows again, but entities don't. So some problems with the pipeline setup I assume.

[lhofhansl]

Shadow issue remain with latest push (antialiasing affecting whether shadows work or not)

[Andrey2470T]

@x2048 I don't understand how to test sun rays effect which judging by your words in 'Postprocessing' Minetest Forums topic you added in this PR. I just don't see those rays neither in MTG nor in Devtest games.

[x2048]

@Andrey2470T , the godrays are on a separate branch, to keep this PR scoped.

[x2048]

@lhofhansl Can it be a driver problem? I can see all shadows with any AA setting (might be AA does not work for me at all?)

[lhofhansl]

@x2048 possible, but not likely. This is with the current Nvidia driver and only with this change.
Lemme try with Intel as well.

[lhofhansl]

Nope tested with NVidia and Intel. Definitely something weird. Shadows are off when starting Minetest, then when switching antialiasing (without existing Minetest) shadows show up again.
Again. With both NVidia and Intel.

It is as if shadows are missing from the pipeline and then added when antialiasing is changed.

[Andrey2470T]

Yes, they render now. I noted the rays will disappear at once as soon as the sun gets outside the player camera view. I don't know exactly whether this behaviour is correct or needs a fix.

[x2048]

@Andrey2470T This is a known limitation, and I've made the transition subtle in the latest commit.

[lhofhansl]

So I'm happy to merge this without the caching. @x2048 do you think that would be OK (is the caching helping much)? Or do do you think we should try to track that down first?

BTW. I tried to check the results of the setters and only cache when the return value indicates success, but that does not solve the problem.

[x2048]

It was a long shot, glad that it worked.

I'd like to try and fix this. Caching uniforms was not without a reason.

[x2048]

Draft documentation on how to play with the pipeline until a better API is created: https://gist.github.com/x2048/7b398f6e10a0f302971d034931dadfa5

[lhofhansl]

FYI. I changed the *ShaderSetting template such that I can control for each instance whether it's cached or not.
If all settings in game.cpp, clientenvironment.cpp, shadowScreenQuad.h are cached everything still works fine, so it must be one or more of the *ShaderSettings in shader.cpp itself.

[lhofhansl]

It's one or more of these in shader.cpp:

	CachedPixelShaderSetting<f32, 16, false> m_shadow_view_proj;
	CachedPixelShaderSetting<f32, 3, false> m_light_direction;
	CachedPixelShaderSetting<f32, 1, false> m_texture_res;
	CachedPixelShaderSetting<f32, 1, false> m_shadow_strength;
	CachedPixelShaderSetting<f32, 1, false> m_time_of_day;
	CachedPixelShaderSetting<f32, 1, false> m_shadowfar;
	CachedPixelShaderSetting<f32, 4, false> m_camera_pos;
	CachedPixelShaderSetting<s32, 1, false> m_shadow_texture;

(Note I added a "cache" parameter to the template).

[x2048]

This is good finding. Did you manage to narrow it down further to a specific setting?

[lhofhansl]

Not, yet. It seems if I cache any of these I see the effect again. I had limited time yesterday, I'll try some more today.

[lhofhansl]

Ok. It's these two:

	CachedPixelShaderSetting<f32, 16, false> m_shadow_view_proj;
	CachedPixelShaderSetting<f32, 4, false> m_camera_pos;

If either of these are cached, shadows sometimes do not display.

[x2048]

Is there a branch somewhere that I could pull in? I guess, we can go with two uncached uniforms and solve it later.

[lhofhansl]

Is there a branch somewhere that I could pull in? I guess, we can go with two uncached uniforms and solve it later.

Not easily right now, sorry.

[lhofhansl]

But here's the simple change to shader.h. And then you can mark the two constants with false.

shader.diff.txt

[x2048]

@lhofhansl Can you try now? I changed what makes the state of PostProcessingStep and which material type is passed when generating the shader.

Edit: It affects how MT shader system caches the material for the post-processing shader, and as a result how that shader works, including when the cached uniform values may be used.

[lhofhansl]

It's still happening :(

[sfan5]

Works on GL and GLES

there's a minor review comment remaining, please address it!

[lhofhansl]

If we merge as is, we should at least avoid caching the two shader constants I have identified as causing the shadow issues.

[x2048]

@lhofhansl I've pushed the changes that disable caching of light space matrix and light vector. Can you verify?

[lhofhansl]

Works.

(BTW. The new volumetric light with bloom is pretty awesome. I hope we can get that one shortly after this.)