Do ive started using the SSGI added in 4.24 and must say it looks awesome so far. However my only downside with it is that it completely removes the SSAO from the post process. Is there another way to introduce AO besides from the AO in the texture for when you build lighting?
Don’t know about the AO but SSGI introduces smears on display especially with more contrasted scenes and fast moving objects, I guess it is the inevitable nature of a post process effect.
4.24 SSGI does it’s own thing for AO it seems, instead of combining SSAO. At least that’s how I understand the code. You can increase the intensity of what is there just by multiplying the final AO, but I’ve yet to get the SSAO pass integrated…
Why would you introduce AO to SSGI though? AO is an old trick originally designed to fake indirect light occlusion in areas lit by fake constant ambient light contribution. Later, in some earlier inaccurate offline renderers, it was used to introduce indirect illumination occlusion detail for extremely inaccurate global illumination solutions, such as Final Gathering in Mental Ray (which had especially poor Final Gather implementation) or Irradiance Cache in VRay.
But SSGI is neither of those. It’s not just constant ambient light, or is terribly inaccurate when it comes to spatial detail density. Introducing AO into SSGI would give you worse, less realistic results and additional computational overhead at the same time. Or in other words, your rendering is slower and you get worse quality in return. A loss/loss scenario.
There seems to be indeed occlusion already built into SSGI already, and I believe that any attempts at artistic control of it will just give you more bias and reduce realism. And trust me, despite what you may think, there’s nothing artistic about overkilled amount of AO in scenes, unless your artistic intent was to simulate consistently uniform accumulation of a smoke ash in concave areas if your map
Old technique != bad technique. And all that unstopable PBRish mania should have boudaries. GIF right before you post clearly show what SSGI + AO gives better results.
Im not saying completely add it SSAO on top of SSGI but might be worth for some artistic control to clamp certain ranges of the AO to further increase the overall quality of the image.
Because SSGI is still a hack and faaaar from anything remotely accurate or even GI, it is a desperate one bounce color bleed on a post process effect and it has tons of its own smears and limitations. AO is what you need to catch those edges, we still use AO heavily in a subtle way on offline raytrace renderers!
Both post process AO and SSGI should be used in a very subtle manner as an addition to whatever base shaders you built any excessive or primary uses of these effects creates horrible visual artifacts during motion and muddy imagery during both motion and stills.
Maybe you should go tell that to ILM, Weta, Pixar, Disney and a numerous other high end Visual effects and CG cinematics companies, perhaps you should go tell them you are doing it all wrong. to this day :).
It is clearly wrong on every level to say that you no longer require AO in new renderers and seems that you fail to understand why we all still use AO to this day! And almost every movie you see out there with characters and environments has AO composited in either in a subtle way or otherwise. From scenes rendered with Renderman to Vray to Arnold! Which is why all high end renderers to this day include AO inside their engines and shaders, even if you are brute forcing GI with 100 bounces in your scenes!
Keeping in mind that the AO in UE4 is NOT the same AO used while compositing a scene with offline renderers, while it gives the same impression it is still a post process effect as mentioned above and is prone to lots of artifacts in motion and in stills as well as wrong shading. AO is not typically composited over the entire scene in a production, we choose which passes get AO and which don’t and how that also effects reflections.
In UE4 I prefer to turn AO OFF entirely and use AO inside the Material shaders directly baked in environments and characters, this also acts correctly since AO will also respect reflectivity or lack thereof when used inside the shader vs used in a post process effect, it is much more work to set it up this way which is why people just turn on post process AO which I think muddies up the image and creates artifacts.
I know quite a few folks from the high end studios you named, and I can assure you most of them don’t use AO as a separate pass they put on top of the renders. AO still has it’s place in form of a map/shader to mask out concave areas for procedural weathering effects, but that’s about it. No competent CG artist in this decade spends additional time and resources to render an additional pass used just to introduce a bias to their renders.
AO in UE4 is present because by default, and also historically, UE4 did not have any realtime GI solution. You have just solid ambient light color which you need to combine with AO to get at least remotely believable result. But if you have an actual accurate GI, which SSGI is, adding more AO will just give you worse results. And there’s nothing artistic about that.
You can clearly see that on the GIF posted above. You can see that SSGI at default setting still creates a lot more pronounced and detailed concave light falloff than SSAO. There’s no need to introduce any more AO on top of that, and you can also see that SSGI with AO set at 1.5 just burns concave shadows, making the light falloff appear lot less realistic.
That doesn’t mean that requirement of “deeper shadows” for artistic purpose is invalid, but that should be done on color grading level, after the rendered result. Not by doing ******** with light transport
I actually work with and have worked in recent past with some of those companies mentioned. I can assure you we all render out passes in form of render elements including an AO pass were required to comp them in later during compositing. Sure you can use them in the shader as well and we do!
But we also choose to render out AO automatically during the main render pass which includes all the separate elements. These are for artistic control. Let us not argue on something I factually know is 100% true today :). I’ve been int he industry professionally for over 25 years now. This doesn’t mean AO is used everywhere it just means it is there when you need it and you will need it during comps.
As for UE4, it is a cheat software, because it is a game engine and serves its purpose as that, SSGI is not an accurate GI solution it is a hack of a hack one bounce color bleed! and a post process at that! it is light years behind anything close to a raytraced GI solution let alone unlimited bounces. Even Epic says use it in a very subtle manner. Which is why some people use another hack called post process AO which suffers form similar problems to make up for others shortcomings. used both together and you will risk getting muddy dirty images. Some care others don’t.
But I mentioned earlier in my post, I don’t recommend using post process AO since it doesn’t give good results, use Material AO for clean results. and work around dynamic contact shadows with other custom setups not requiring post process AO.
If anyone is interested on implementing hdri and raytracing including ssgi I did a little tutorial that hopefully clarifies some things out and could be useful to some people trying things out. The whole raytracing system including the ss stuff is a little particular but once you understand what to turn on and off it works great out of the box! Anyway hope you guys find this useful:
Indeed, aren’t there custom surface biasing for lightbounces now? I know at least Renderman does it this way, and it’s still one of the most popular production renderers.
I actually work with and have worked in recent past with some of those companies mentioned. I can assure you we all render out passes in form of render elements including an AO pass were required to comp them in later during compositing. Sure you can use them in the shader as well and we do!