Implement MSAA

[VReaperV]

Implements #532.

Add r_msaa. When set to > 0, an MSAA FBO will be created with that many samples. This FBO will be used for rendering, other than when it requires sampling from current render/depth image. When such rendering is required the MSAA FBO will be blit into the main FBO and vice versa, to resolve the MSAA texture.

plat23:
No MSAA:

MSAA 4x:

thunder:
No MSAA:

MSAA 4x:

MSAA 16x:

MSAA 32x:

[illwieckz]

Nice! Finally some antialiasing!

It looks like when MSAA is enabled the heathaze from back surface is applied on front surfaces too:
https://imgsli.com/MzMyODgx

[illwieckz]

My previous comment was about screenshots from the original post.

When I try the branch and enable MSAA I get a black screen (AMD Radeon with Mesa radeonsi driver).

[VReaperV]

When I try the branch and enable MSAA I get a black screen (AMD Radeon with Mesa radeonsi driver).

That's interesting. Can you try with effects that use the main render target disabled, like heatHaze, bloom etc (or just use the lowest profile to make sure)? Also, does it work in the main menu?

[slipher]

I get a completely black screen (other than 2D drawing) with r_msaa 4 or 16 on Spacetracks. Plat23, on the other hand, renders. I tested with Nvidia on Windows; default cvars except with reliefmapping enabled.

[slipher]

Actually it's just black from whenever the 2nd map is loaded. Must be some cleanup bug

[illwieckz]

Can this be rebased on current master? 🙂️

[VReaperV]

Can this be rebased on current master? 🙂️

Done... but I haven't tested it after rebase, so I don't know if it still works lol.

[illwieckz]

It looks like the rebase went wrong! 😅️

/home/vsts/work/1/s/src/engine/renderer/tr_backend.cpp:3105:1: error: expected expression
<<<<<<< HEAD
^

[VReaperV]

I get a completely black screen (other than 2D drawing) with r_msaa 4 or 16 on Spacetracks. Plat23, on the other hand, renders. I tested with Nvidia on Windows; default cvars except with reliefmapping enabled.

Actually it's just black from whenever the 2nd map is loaded. Must be some cleanup bug

It looks like the rebase went wrong! 😅️

/home/vsts/work/1/s/src/engine/renderer/tr_backend.cpp:3105:1: error: expected expression
<<<<<<< HEAD
^

All fixed.

[VReaperV]

Nice! Finally some antialiasing!

It looks like when MSAA is enabled the heathaze from back surface is applied on front surfaces too: https://imgsli.com/MzMyODgx

The heatHaze is wrong because the heatHaze itself is drawn into the regular framebuffer, so this is an aliasing issue. It might be possible to make heatHaze render into an MSAA FBO, but I'm not sure it's worth the performance hit, since heatHaze with MSAA currently works as:
Resolve MSAA into main -> use main to render heatHaze surfaces into the other main FBO -> bind the other main FBO -> render distorted heatHaze surface from the first main FBO -> transition back into the MSAA FBO

To fix it, it would have to be:
At the start, create another MSAA FBO
Resolve MSAA into main -> use main to render heatHaze surfaces into the extra MSAA FBO -> resolve the extra FBO into other main FBO -> bind main FBO -> render distorted heatHaze surface from the other main FBO -> transition back into the MSAA FBO
Which adds more rendering into MSAA targets and extra resolves (the extra resolves could also be more of an issue if material system is disabled, since the core renderer doesn't group drawcalls anywhere as efficiently).

[slipher]

Works great on my favorite jaggies test case from Spacetracks!

Default:

With r_msaa 1 - somehow a lot better already. Is that even supposed to be different from having it off?

r_msaa 64

[VReaperV]

With r_msaa 1 - somehow a lot better already. Is that even supposed to be different from having it off?

It's most likely that the driver is actually using a higher value. The spec says:

samples represents a request for a desired minimum number of samples.
Since different implementations may support different sample counts for multisampled textures, the actual number of samples allocated for the texture image is
implementation-dependent. However, the resulting value for TEXTURE_SAMPLES
is guaranteed to be greater than or equal to samples and no more than the next
larger sample count supported by the implementation.

[illwieckz]

On my end it now works. I still get a black screen on AMD and Mesa when I use values higher than 8, but maybe we can cap that.

[VReaperV]

On my end it now works. I still get a black screen on AMD and Mesa when I use values higher than 8, but maybe we can cap that.

Does it say in the log that the samples requested were too high and it's falling back on some other value? According to https://opengl.gpuinfo.org/displaycapability.php?name=GL_MAX_COLOR_TEXTURE_SAMPLES, 8 is indeed the max for AMD, but the renderer should be automatically using that value if you specify a higher one.

[illwieckz]

Using 4 dynamic light layers, 64 dynamic lights available per tile 
Warn: MSAA samples 9 > 8, setting to 8 
The change to r_msaa will take effect after restart. 
Warn: R_CheckFBO: (msaa) Framebuffer incomplete attachment 

After another vid_restart it works. So I guess we face some mess with the latching.

[illwieckz]

We probably need something similar to this, but for r_MSAA:

	// HACK: We want to set the current value, not the latched value
	Cvar::ClearFlags("r_customwidth", CVAR_LATCH);
	Cvar::ClearFlags("r_customheight", CVAR_LATCH);
	Cvar_Set( "r_customwidth", va("%d", windowConfig.vidWidth ) );
	Cvar_Set( "r_customheight", va("%d", windowConfig.vidHeight ) );
	Cvar::AddFlags("r_customwidth", CVAR_LATCH);
	Cvar::AddFlags("r_customheight", CVAR_LATCH);

[VReaperV]

Ah, yes. I'll add that a bit later.

[slipher]

We probably need something similar to this, but for r_MSAA:

Well that's only needed if you really want to use the cvar as a status display for the currently used value. Normally we try to avoid modifying cvars, and would store the current value in glConfig.msaa or something like that.

[VReaperV]

That's an option too.

[illwieckz]

The glConfig.msaa way is fine.

[VReaperV]

The glConfig.msaa way is fine.

That part is done now.

[slipher]

There's a bug - dynamic lights are not rendered when MSAA is enabled.

[slipher]

Also depth fade isn't working. It looks the same as if depth fade were disabled.

[slipher]

Also I confirm what illwieckz observed long ago about heat haze penetrating opaque surfaces. Try the following commands and you will see heat haze on the other side of a door being rendered.

devmap chasm
setviewpos -634 67 79 -178 4
testshader gfx/weapons/flamer/haze

[VReaperV]

Also depth fade isn't working. It looks the same as if depth fade were disabled.

Fixed.

Also I confirm what illwieckz observed long ago about heat haze penetrating opaque surfaces. Try the following commands and you will see heat haze on the other side of a door being rendered.

devmap chasm
setviewpos -634 67 79 -178 4
testshader gfx/weapons/flamer/haze

Also fixed now.

[VReaperV]

There's a bug - dynamic lights are not rendered when MSAA is enabled.

Fixed this too.

[slipher]

In the latest version, some transparent surfaces are no longer rendered. For example in the Vega scene below, the cone under the globe and the alpha-tested grates are missing. Also fogs are gone.

[VReaperV]

In the latest version, some transparent surfaces are no longer rendered. For example in the Vega scene below, the cone under the globe and the alpha-tested grates are missing. Also fogs are gone.

Both fixed now.

[slipher]

Turning on r_msaa causes tone mapping to be disabled in my tests. This is the same issue as I saw in #1684 (comment) (but this time I took screenshots with r_toneMapping 0 to confirm that this is what is happening). I can't reproduce it manually, only in scripted tests, so I need to do more investigation on how to reproduce it.

[slipher]

Also color grading is missing in my tests so it's like the whole cameraEffects shader is skipped?

Besides that there are just a couple minor issues that I would consider non merge-blocking, at least if we call it an "experimental" feature:

• SSAO does not work.
• I get this seam in the atcshd fog. Maybe I made a mistake in the recent fog rewrite.