renderer: split generic and generic3D

[illwieckz]

Split gl_genericShader and gl_generic3DShader.

• Dedicate a simple shader without extra uniforms and no permutations for simple things like debug tools.
• Make sure to not have to call this boiler plate everywhere:

gl_genericShader->SetVertexSkinning( false );
gl_genericShader->SetVertexAnimation( false );
gl_genericShader->SetTCGenEnvironment( false );
gl_genericShader->SetTCGenLightmap( false );
gl_genericShader->SetDepthFade( false );
// should be done there: gl_genericShader->BindProgram( 0 );
gl_genericShader->SetUniform_AlphaTest( GLS_ATEST_NONE );

• Leverage more of the compiler type checking at build time.

Here are the current usages:

• gl_genericShader: Mostly used by debug tools and things only requiring a very simple shader.
• gl_generic2DShader: Used for 2D UI elements, it has special code for RmlUi transforms.
• gl_generic3DShader: Full-featured shader for stages with a single texture.
• gl_lightMapping: Full-featured shader for multi-textured stages.

The generic2D and generic3D names are temporary names, we can rename them later to something more meaningful, as 2D and 3D can be confusing with 2D and 3D textures but they both receive 2D textures, we may rename them like genericUI and generic<SOMETHING>. The Render_generic2D, Render_generic3D and the Render_generic wrapper (that only calls code using gl_generic2DShader and gl_generic3DShader) may be renamed too in the future.

If it happens that by doing so when compiling gl_genericShader we recompile a shader that already exists as a permutation of gl_generic3DShader, we may improve caching to deduplicate them (this may even deduplicate some gl_generic2DShader too):

• If two shaders / permutations produce the same code, do we compile them twice? #1435

This split has nothing to do with light overbright, I first implemented it as part of my overbright efforts because such overbright effort was one of the use case where such changes having already be made before would have make things easier. The overbright effort just reminded me I wanted to do that for a long time, so I decided it was the right time to finally do it.

[illwieckz]

This is to be merged after:

• Simplify overbright implementation #1406

As this assumes this other branch is already merged (hence the temp commit to fix the build).

[illwieckz]

The only usage of gl_genericShader seems to be:

• DebugDrawBegin(),
• RB_RunVisTests(),
• RB_RenderDebugUtils() (for many debug utilities),
• RB_ShowImages() (another debug utility),
• the to-be-removed legacy shadow map code in RB_SetupLightForLighting.

They all live in tr_backend.cpp.

The DrawTris() function from tr_shade.cpp that can be seen as a debug utility uses gl_generic3DShader because it has to process the same transformations as gl_generic3DShader or gl_lightMappingShader. The the only difference with them is to render some wires instead of textures.

[illwieckz]

Also, there may be no need for any gl_genericMaterialShader variant.

Only gl_generic2DMaterialShader and gl_generic3DMaterialShader variants look to be needed.

[slipher]

gl_generic2DMaterialShader

Should never need to exist.

We could get most of the benefit of boilerplate reduction by switching off GLSL macros en masse rather than one at a time, replacing

gl_genericShader->SetVertexSkinning( false );
gl_genericShader->SetVertexAnimation( false );
gl_genericShader->SetTCGenEnvironment( false );
gl_genericShader->SetTCGenLightmap( false );
gl_genericShader->SetDepthFade( false );

with

gl_genericShader->DelMacroBit(-1);

[illwieckz]

Yes but there is still a one-line boilerplate to be copy-pasted every time gl_genericShader is used in those functions (currently 12 times), plus the one-liner uniform boilerplate to be done 12 times too.

And a type can do it better.

[VReaperV]

• gl_generic3DShader: Full-featured shader for stages with a single texture.
• gl_lightMapping: Full-featured shader for multi-textured stages.

I believe lighting here is the more important distinction (height maps, normal maps etc. also have to do with lighting).

[VReaperV]

gl_generic2DMaterialShader

Yeah, I don't see the point in that either, UI wouldn't benefit from it, and generating materials for UI wuld require rewriting a lot of code.

[illwieckz]

gl_generic2DMaterialShader

Yeah, I don't see the point in that either, UI wouldn't benefit from it, and generating materials for UI wuld require rewriting a lot of code.

That part was just my memory being wrong. That doesn't change the fact there may be no need for a material variant of such stripped down generic shader, unlike the generic3D one, which is what I wanted to say.

[illwieckz]

I wonder if such simple shader would be reusable for displaying a startup logo as soon as possible:

• Display a Dæmon logo at startup, before everything else can be displayed and before the game can do anything #384

It would then be the very first shader being compiled, maybe not having permutations and being simple may help for having it built as soon as possible?

[VReaperV]

gl_generic2DShader: Used for 2D UI elements, it has special code for RmlUi transforms.

This will no longer be the case after #1439 is merged, so it can then be merged with the 3D shader. The GENERIC_2D will then only be used by the shader profiler.

[slipher]

Since it turned out that 2D drawing doesn't actually need any special GLSL, I might make a very basic shader to be shared by 2D and debug drawing. But as a different GLSL source file please, not more macros on generic!

[illwieckz]

The new insert mechanism may be usable to share possible common code if needed, the generic macro creep was basically a workaround for no insert.

[slipher]

This shader would have less than 10 lines in its main functions so no need to share anything.

[illwieckz]

Does 2D transformation require some vertex complex code?

[VReaperV]

Nope, it's just vertexSimple.

[illwieckz]

Nice!