Feature Request Small feature extensions to SSGI that will make it feasible to use

After playing around with SSGI quite a bit and also having some discussions here recently on the forum, I've come to the conclusion that without some changes or small improvements, it is just not practical to use in games where you have a 3rd person character running around (based on my first hand experience that all of the perceivable issues I have with SSGI usually relates to our character on the screen).

Issues include:
- Very bad noise on our character (while the static environment looks good).
- Trails due to slow denoising over many frames.
- Weird super bright indirect light contribution from clothing or skin onto character itself or surroundings - its as if the character is made of flashlights.

I would love to see the following tweaks to SSGI:

1. Intensity slider. In the same way we use an intensity slider in SSAO (for example) to mitigate noise or other issues, it would be great to be able to simply reduce the overall contribution of SSGI vs. the original image, using a simple slider. This will reduce most of the artifacts in the images and videos I have attached, and will also let us control the indirect light contribution, which in my tests, are far too bright in some cases.

2. Exclude selected objects from contributing or receiving GI.
This could be done in any way that gets the job done... at renderer level, material property, render layers or regular old game-object layers... just anything that will work so we can exclude problematic objects.

Here are some shots showing some of the issues. Note - I have increased the Depth Tolerance value here to exaggerate the "trail" issues - nevertheless the issues are still there even when dialling down most properties.












And here's a video:

 

Sorry for trivial question, but why choose HDRP for a highly stylized game? I completely despise URP (as HDRP user myself), but asset store is so filled with shaders and fixes that closes the gap between these both pipelines (most of the shaders are gimmicks, but anyways)

As for GI, it's completely unusable, I'd say wait for H-Trace 2.0 this is what everybody waiting for (basically Lumen for Unity)
There's also APV solution for pre-baked GI, but lacks dynamics.

 

Currently I am indeed waiting for H-trace 2, yes.

Regarding the comment about choosing HDRP:

It's worth noting that the game is not stylized to the point of being a simple cartoon. I guess the in-development images I drop here can be a little misleading in this regard, because it does not show the overall detail and richness of the features and game world in its totality.

We're going for very high quality surfaces and lighting (e.g. our props and related customization system), complex indoor and outdoor dynamic environments, day/night / weather blending, high detail forests and other biomes, a massive open world made out of dozens of stitched terrains, etc. All of this is basically "coated" in a stylized layer mainly via texturing choices.

(have a peak: https://twitter.com/farmfolksgame)

So it basically came down to this... built-in vs URP vs. HDRP. I discounted built-in straight away, because I'm in love with the amazing modern volume framework and of course there's the fact that URP/HDRP is better aligned with the future of Unity. There are many nice things about the more modern URP/HDRP approach that I love.

Now the choice came down the URP vs HDRP, and quite honestly, URP is utterly crippled for our purposes. To mention just a few things from the comparison table (Unity - Manual: Render pipeline feature comparison (unity3d.com)) which is not in URP:

- DLSS
- Custom passes (we have many)
- GPU tessellation
- Local volumetric fog
- Volumetric clouds
- Good volumetrics in general
- Indirect lighting controller
- Software dynamic resolution
- Shadow cascade blending
- Area light shadows
- Mixed cached shadows (maybe in URP?)
- SSGI (H-Trace 2 maybe)
- SSR
- Ray traced AO (for high end)
- Water system (potentially, in the future)
- Gradient Sky
- Powerful decals (emissive, etc)

We also have a 12-layer single pass terrain shader (modded HDRP shader). We do some pretty complicated compute shaders in combination with custom passes, for dynamic occlusion culling. We render many dozens of deferred lights simultaneously (I don't know if the recent support of deferred in URP is any good?). There is a long list of why URP is simply too limited for our purposes.

Now you mention closing the cap via asset store - but here we've been burnt badly in the past, especially when relying on asset store stuff over major Unity version changes.

I guess I decided to take a bet on HDRP giving us all we need out of the box (or at least 90%), and so far it is paying off OK, with the exception of the crippled SSGI and a few other issues here and there.

 

check out SSRT in the asset store, very impressive SSGI for HDRP with APV fallback. Really adds depth to your scene, everything feels more realistic. Less noise.

 

I looked at this one recently (https://assetstore.unity.com/packag...ects/ssrt3-screen-space-ray-tracing-gi-234143), but probably avoided it due to low review count (can't remember exactly).

Since you've worked with it already, can you please confirm that it does not suffer from the issue that the "Horizon Based Ambient Occlusion" asset has? See first review and dev's response: Horizon Based Ambient Occlusion | Fullscreen & Camera Effects | Unity Asset Store

The problem is that there's no injection point to do SSAO prior to volumetric fog, so in a foggy environment the occlusion will show through the fog. This is a bit of a breaking issue IMO. I wonder how the SSGI3 system deals with bad injection points?

 

Looks like it doesn't suffer the same issues, but I'm not sure.
Worth noting that the scene in this video has APV baked, so the volumetric fog samples scene APV indirect lighting/color.

I exaggerated the GI in the video to focus on the GI from the asset. Ignore the menu issues, that's a unity bug in the version I'm using.

 

Thanks for the video!

Interesting - looks like it works, at least with APV. But we don't have APV (2022.3.x does not have it I think), so I will probably need to take a chance and see how this plug-in performs in a totally dynamic open world environment with no probes.

 

I have a very strong love hate relationship with APV.
It breaks down in interiors, you will struggle _endlessly_ with lightleaks. It is unbelievable how annoying it is.

The only way to avoid that is to do one or more of the following:

1. Build your meshes to be VERY thick, and hope that's enough (most likely is not).
2. Spend a disgusting amount of time placing probe adjustment volumes, setting up virtual offset volumes, etc.
3. Never have very low light or dark areas, ensure your room/area receives a lot of indirect light. That way all light leaks and issues are just covered up by indirect lighting.

4. Use an insane probe density (might still not be enough, also depending on your scene, you might spend hours or more on baking, and the disk size will be absolutely ridiculous, the more probes you have, the more samples you will need for a clean noise-free result)

#3 is how unity mostly did its cinematic demo. And that was just one tiny room.

it's really hard to scale APV to bigger levels. The only exception is a complete exterior environment, forest, etc.
I have a tiny dungeon like level/interior, and the issues never end. Either black unexplainable splotches, point lights leaking light somehow 100 meters away, or the usual severe light leaking from the sun. Not fun. The anti-leak mechanic they used was a cheap solution, mostly used just for how cheap it was. (I guess due to URP considerations).


I heard virtual offset will be improved in the future, so hopefully that helps, because most of the time it doesn't work as it should.

Also, APV is available in 2022.2 for HDRP. Not labeled production ready though.

 

Well.. our game lets players build whatever they want in a dynamic open world, like entire houses and stuff. I just don't see APV being feasible, unless it is some future version of Unity where it is truly dynamic and automatic without manual tweaking by devs / artists.

 

Thanks for large answer, HDRP projects are quite rarity most of the time, especially with such large capacity like this one, but what about FPS metrics? Almost nobody sharing anything regarding performance.
(speaking from your screenshots with SSGI on, I can assume without it about 80-90 FPS right?)

 

BTW - I think we've gone totally off topic, but this is interesting anyway, so forgive me

When it comes to performance issues and how to resolve them, I can only talk about built-in pipeline and HDRP, since I have zero experience in URP.

There are some seemingly fixed overheads in HDRP that immediately puts a fairly simple scene at a frame rate where people with BIRP experience go... "hang on, my empty scene ran at 3000 fps in BIRP, and now in HDRP it is running at 140". But it doesn't make much sense to compare this way, because a simple HDRP scene is already doing a huge amount of ground work with many dozens of passes. Just look at the "injection points" diagram to see just the sheer amount of steps in the pipeline... Injection Points | High Definition RP | 14.0.8 (unity3d.com)

But, from here on, it seems to scale really well and keep more of a predictable and steady frame rate as you throw more stuff at it.

But nevertheless, the fixed CPU overhead of HDRP (at least v14) seems pretty high, and I hope it will be improved and reduced over time. I haven't tried v15 or v16 yet.

We are also having huge issues with DX12 performance that halves our frame rate compared to DX11, with no good explanation currently. So I'm sticking with DX11 obvisouly.

To specifically answer your question about frame rate - I'm getting around 100-120 FPS in a release build, with basically most of the features of HDRP switched on, including volumetrics, volumetric clouds, many post processes, many active lights, and very expensive pixels (in terms of shader complexity and total post processing per pixel etc). I have a RTX 2060 and running 1440p. Note - the editor frame rate is substantially lower that what I get in a release build.. not even in the same ballpark.

To maintain this kind of frame rate, we rely absolutely on DLSS and FSR2. I find that smart upscaling is crucial for HDRP to perform well when you target 4K and even 1440p.

It's not just DLSS - we have to do quite a bit of work to really get where we want to be performance-wise:

- We have a custom dense grass and foliage system that will use compute to create combined grass/flower tiles per material near the player, and then release these resources when the player leaves the area.
- Our artists build our town out of tiny modular prefabs - again this is combined dynamically per material at run-time, including combined meshes for Unity's LOD system.
- Both the above run in the context of a custom quad tree system that will simply switch off entire parts of the world not in view or too far away.
- We have a custom render pass working in combination with a Job that will do occlusion culling, basically switching off all details like windows, doors, props and thousands of other things that are not visible in the current view.
- The list goes on...

So in summary, in some ways the unavoidable overhead and overall performance of HDRP does suck a bit, but I'm willing to live with this and come up with pretty complicated solutions to manage frame rate, in exchange for getting all the rich features out of the box.

 

OK, I've done some tests with SSRT3 (from the asset store) with the following results...

I found that without DLSS or FSR2 upscaling, the quality looked good for both GI and AO - however... similar to Unity's SSGI it can eat a lot of frames. For example in the editor, dropping fps by 30% when SSRT3 enabled on my 1440p display.

So my tactic to deal with expensive pixels has been to rely on DLSS and FSR2, with some amazing results because it's hard to tell the difference sometimes, but the rendering overhead is so much lower.

Now the issue in the case of SSRT3, is that the GI aspect does not seem to play well at all alongside DLSS. Specifically:

- With temporal accumulation and denoising checkboxes off, GI has a harsh grid-like dithered look where huge "pixels" are visible... clearly operating in the original smaller buffer size before the upscaling phase.
- Switching on only temporal accumulation, gives a clean result, but it gives severe ghosting as seen in the beginning of the video (check the left side of the screen)
- Switching on both (temporal + denoise) fixes the ghosting, BUT brings back the grid-like pixels. It seems at least with DLSS on, the denoising makes things worse instead of better.

Throughout the video I play around with the combinations of those checkboxes, as well the sliders. Some parts of the video is zoomed:

 

I think you can write the same post to creator via mail or other social platforms, so it could be better with your real feedback usage

 

Hey,
I want to mention that I very strongly suspect a large error somewhere in the final compositing of the rendering features, especially related to GI. At first I thought the SSGI is not well done and extremely weak, but then a year later, testing the Raytracing features, it seems like the Raytracing features have the exact same issues and visual outcomes.

There is clearly a strong commonality between SSGI, RTGI, RTAO, and they have a very weak and in many or even majority of areas very low impact on the final image compared to third party implementations or implementations from other engines.

I strongly suspect that there is a compositing error somewhere in the final steps or that they share some faulty calculation somewhere. A wrong gamma curve that is being shared or something like that, as all these are extremely weak and can in most cases only show a real difference once reflection probes are disabled compared to the default state with reflection probes. We have very different scenes and tried varied scenarios, and our game is full of strong colors, yet we gain virtually nothing from SSGI or RTGI / RTAO in visual quality, while SSRT (Third Party) makes a very major and instantly noticeable difference in both GI and AO.

Let me know if you need some examples in case someone is investigating.

 

@OP
1. Intensity slider.

You can set the intensity by adding a indirect lighting controller to your volume
its also recommended to remove the reflection probe lighting while using SSGI as far as I understand, through the same controller

 

Yes we have an indirect lighting controller and we use it - but it does not allow you to control *only* the contribution of SSGI vs. the original image. What we need in the form a an intensity slider, is a bit different from simply messing with the overall brightness of indirect light.

 

To be a bit clearer - by "intensity" slider, I do not mean the brightness of the GI. I mean the influence (0 to 1) that the SSGI override has compared to the original image (i.e. with SSGI check off). As I mentioned previously, a direct example of this is the SSAO override. You can enable it, but then use the slider to control its intensity. This is useful for hiding noise issues, etc. at the expense of less occlusion.

 

There is nothing wrong with the final composition, but you need good understanding of exactly which parts of the composition are filled in with ray tracing, where the ray tracing gets their contribution from, what to expect from a low sample count and what is lost due to the denoiser.