Resolved Graphics look worse when SSGI is enabled

SSGI enabled:


SSGI disabled:


This is the default HDRP sample scene. I can't believe this is by design - this must be some kind of bug by the looks of it.

 

I mean realtime solutions can't really look as good as high resolution pre-baked lighting.

 

They are both prebaked.

 

SSGI isn't prebaked

 

The scene has prebaked lighting. it is the exact same scene with the exact same prebaking with the exact same settings but SSGI enabled on top.

 

From the manual.

 

so it is by design .

 

I mean, the benefit is that it has zero authoring and you can move lights and have procedural meshes contributing light at runtime.

I don't like how it looks either, but it's not supposed to replace lightmapping in terms of quality, it's supposed to allow you to do stuff you couldn't before.

 

Of course, that's 100% true. However I don't see any reason at all to replace all lightmap/lightprobe data due to enabling SSGI. If light data is being baked, it is being baked for a reason. The idea of SSGI should be to enhance image quality independently of light data being previously baked or not. If I don't want baked data but SSGI only, I can remove baked light data myself or just not bake it in the first place. Using SSGI as an enhancement independently of light data being previously baked or not could be a way more usefull solution than the current implementation.

 

SSGI is not just to dynamically add indirect illumination - it ambiently occludes as well as globally illuminates. So it makes no sense to use baked data and real-time data at the same time. It is conceptually the same data (or similar), being calculated in different ways (pre baked vs. real-time). You can't occlude the dark area behind your pillars twice.

 

I try to look at this outside the box, for example:

1) baking APVs with somewhat generic light conditions and using SSGI on top for alowing slightly dynamic light modifications at runtime
2) using SSGI in combination with APV to improve light-leaking artefacts
3) using SSGI in combination with APV to improve overall GI when possible (sometimes high resolution screen space data can be used to improve low resolution APVs)
4) using SSGI on specific layers only (for example dynamic objects) while the rest gets baked

 

I guess it would only make sense if they explicitly implement a mode that understands that both are being used, so that the data doesn't "clash".

Your point 4 about layering is pretty important, but missing right now. We don't do any baking, but in our case I really wish to exclude some objects from the SSGI, because of bad noise. Specifically, if I apply SSGI to our town buildings (macro scale stuff), it looks nice, but on our character it looks horrendous due to noise and other artifacts, so it would be great to somehow mask out which objects should receive SSGI. Additionally, some slider to adjust the overall strength of the SSGI would be great, so that noise and artifacts can be mitigated in a similar way that we can do with SSAO (simple slider).

 

Screen space gi is not real GI, just looks at what is on screen, this is just wrong lighting.

That is why i made the above system for real time voxel based gi that is a real fully global illumination solution like Unreal Lumen.

Another example below that screen space will not work correctly, when light is in front of camera but occluded by obstacles, like in the cave below