DaemonEngine
Implement MSAA
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:
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
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).
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?
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
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.
It looks like the rebase went wrong! 😅️
/home/vsts/work/1/s/src/engine/renderer/tr_backend.cpp:3105:1: error: expected expression
<<<<<<< HEAD
^
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.
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).
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
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.
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.
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.
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.
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);
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.
Also depth fade isn't working. It looks the same as if depth fade were disabled.
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 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.
There's a bug - dynamic lights are not rendered when MSAA is enabled.
Fixed this too.
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.