[2.2] Bug combining SSR with MSAA
-
- Gnoblar
- Posts: 12
- Joined: Wed Feb 12, 2020 3:16 pm
[2.2] Bug combining SSR with MSAA
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
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
- dark_sylinc
- OGRE Team Member
- Posts: 5299
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1279
- Contact:
Re: [2.2] Bug combining SSR with MSAA
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.
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.
-
- Gnoblar
- Posts: 12
- Joined: Wed Feb 12, 2020 3:16 pm
Re: [2.2] Bug combining SSR with MSAA
Thanks for the reply and explanation. It's sad to hear that it remains unsolved.
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.Given the little attention that our SSR implementation is getting (it's slow, SSR in general is a vast disapointment in terms of results)
- dark_sylinc
- OGRE Team Member
- Posts: 5299
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1279
- Contact:
Re: [2.2] Bug combining SSR with MSAA
There are 5 main families of solutions for reflections: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.
- 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).
- 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)
- VCT: Voxel Cone Tracing. They give you rough reflections. For very rough reflections, they're very good. Also static like PCC.
- Planar reflections. The best solution.... if the reflective surface looks like close to a flat surface.
- Raytracing. The ultimate solution
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).
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)