[2.2] Bug combining SSR with MSAA

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
m00ggi
Gnoblar
Posts: 12
Joined: Wed Feb 12, 2020 3:16 pm

[2.2] Bug combining SSR with MSAA

Post by m00ggi »

Hey,
I found out that combining SSR with MSAA causes an known error (see viewtopic.php?t=92708).
This error was reported for Ogre 2.1 using Dx11 and I found several commits on Github, but unfortunately this error still occurs in Ogre 2.2.4 using OpenGL and DirectX (I'm using OpenGL on an AMD system, but I checked the SSR-Sample with both render systems).
As far as I investigated all fixes should be included in version 2.2.4, so my question is:
Is it possible to fix this problem or will there be a fix in the future? Or did I miss something important?
SSR would be almost useless for me if I couln't combine it with MSAA.

Thanks in advance!
m00ggi
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.2] Bug combining SSR with MSAA

Post by dark_sylinc »

I replied to you... in my head. And forgot to write it down.

SSR and MSAA was troublesome because GPUs don't really bring a lot of tools to deal with it properly so the solution was more a heuristics. That combined with GL driver errors which prevented the solution from working at all, thus SSR + MSAA did not end up having a solution in GLSL (that was like 2 years ago, should've been fixed by now), but there is for HLSL.

Given the little attention that our SSR implementation is getting (it's slow, SSR in general is a vast disapointment in terms of results), it remains unsolved.
m00ggi
Gnoblar
Posts: 12
Joined: Wed Feb 12, 2020 3:16 pm

Re: [2.2] Bug combining SSR with MSAA

Post by m00ggi »

Thanks for the reply and explanation. It's sad to hear that it remains unsolved.
Given the little attention that our SSR implementation is getting (it's slow, SSR in general is a vast disapointment in terms of results)
What would you prefer instead of SSR? I can't imagine that dynamic local probes are much faster than SSR. And there is the point with placing them in the scene.. Our visualization will mainly take place outside with the possibility of procedural creation. So I thought screen space algorithms are the easiest way to achieve "good" and "fast" reflections/ambient occlusion. Your answer leaves me in doubt.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.2] Bug combining SSR with MSAA

Post by dark_sylinc »

m00ggi wrote: Wed Mar 17, 2021 10:10 am What would you prefer instead of SSR? I can't imagine that dynamic local probes are much faster than SSR. And there is the point with placing them in the scene.. Our visualization will mainly take place outside with the possibility of procedural creation. So I thought screen space algorithms are the easiest way to achieve "good" and "fast" reflections/ambient occlusion. Your answer leaves me in doubt.
There are 5 main families of solutions for reflections:
  1. Screen Space. Looked like a silver bullet, looks like s**t in reality. There are exceptions (e.g. looking at a lake). Our implementation could be faster (probably by using more compute instead of pixel shaders, and trying to use depth buffers to speed up the ray marching step).
  2. PCC (Parallax Corrected Cubemaps). We have per pixel PCC in Ogre 2.2. But indeed it's not the best for real time update of the probes. You may get away with a few tricks if almost everything is static except a few objects (bake the static contenst in a cubemap, then every frame copy the cubemap and render the dynamic objects on top)
  3. VCT: Voxel Cone Tracing. They give you rough reflections. For very rough reflections, they're very good. Also static like PCC.
  4. Planar reflections. The best solution.... if the reflective surface looks like close to a flat surface.
  5. Raytracing. The ultimate solution
90% of games use static reflections, not dynamic (except for the main character). Mostly coming from PCC. The other 10% either uses planar reflections or screen space. Or a combination of everything.

It all sucks, which is why you may have noticed there's a huge boom in HW accelerated raytracing. It's the only solution that fixes the problem cleanly and with acceptable tradeoffs (speed, quality, difficulty of implementation, harmony with other techniques).
m00ggi wrote: Wed Mar 17, 2021 10:10 am So I thought screen space algorithms are the easiest way to achieve "good" and "fast" reflections/ambient occlusion
Ambient Occlusion is quite different. SSAO is often good enough (unless you're picky). Our VCT structures could be used for implemented AO too, but we didn't write the code for that (often because VCT being used for GI already gives superb results)
Post Reply