Sign in to follow this  

What physical phenomenon does ambient occlusion approximate?

This topic is 1042 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I understand that ambient occlusion is a simplification of, or a partial solution to, global illumination.  How this interacts with physically based rendering is less clear, however, as at face value ambient occlusion is creating light from nothing.

 

The domain for ambient occlusion at a given point is the hemisphere around the tangent plane to the surface at that point, and ambient occlusion is considered to be indirect lighting.  However, if you narrow down that domain to the silhouette of an area light, you get direct lighting, which is already computed and occluded using a shadow map.

 

This gets confusing, since for sunlight, BOTH techniques are commonly used.  How do you account for the energy transfer from direct sunlight to indirect sunlight (ambient light)?  I'm assuming it's related somehow to the atmospheric scattering of a scene, because as a scene gets more overcast and less sunny, direct lighting is reduced while indirect lighting is increased.

 

So this means that lots of different scattering phenomena can contribute to ambient lighting: air, clouds, fog, water (for an underwater scene), and so on.  How do you deal with all of this in a way that conserves light, or at the very least does not create extra light (losing light is more acceptable, in my humble opinion)?

Share this post


Link to post
Share on other sites

I didn't mean to imply that I wanted to replace direct sunlight rendering with ambient occlusion.  I'm simply wondering how to keep the contribution physically correct and variable depending on the environment.

Share this post


Link to post
Share on other sites


I'm simply wondering how to keep the contribution physically correct and variable depending on the environment.

 

I'm not sure it's realistic to make things like the sky brightness physically correct. Clouds might give off more light than a clear blue sky, but it's going to depend on so many factors. Probably more practical to just have some artistic control that is modulated by the overall sunlight.

 

For the "ground" part of your sky dome, the amount of light given off can be calculated assuming you know the approximate albedo of the ground and the amount of light coming from the sun or top half of the sky dome.

 

I did some experiments to try to improve my ambient lighting which may be of interest:

https://mtnphil.wordpress.com/2014/05/03/global-illumination-improving-my-ambient-light-shader/

Share this post


Link to post
Share on other sites

From some thinking and prototyping, I think what I want to do is at least separate the indirect sunlight portion of ambient lighting from surface emissivity.  This should allow me to more easily physically define the energy transfer between direct sunlight and indirect sunlight, i.e. sunlight that has been scattered in the atmosphere.

 

What I'm stuck on right now is a way of determining sky occlusion.  Since I should be able to represent my world quite trivially with a signed distance field, I figured that was the best place to start.  I first tried ray marching, which gave good results but required too many samples in the worst case (though perhaps dynamic branching will be cheap enough to offset this with early-out tests?)  I thought about trying to figure out a heuristic-based approach, since at the end of the day I don't require a contact solution, only whether or not there is an intersection.  However, I can't think of a way to do this without a lot of incorrect occlusion samples.  In practice this might turn out to be acceptable, but I won't know until I implement it.

 

Am I barking up the wrong tree here or am I just missing some key technique?

Edited by Boreal Games

Share this post


Link to post
Share on other sites

How this interacts with physically based rendering is less clear

ambient occlusion ist not physically correct, every rendering that uses it is breaking all the previous effort to be energy conserving.

It is also calculated in a different way, not just tool to tool, but also two artist sitting next to each other will create a different occlusion map. Imagin a big building and the definition that AO captures the direct lighting of the skydom, that implies that most areas inside the building would have plain black AO.
That would look ok'ish for a game like SimCity, but what would be the point in creating 99% black maps in indoor games? so artist tweak the outcome to be maybe just occlusion from close by objects. some save the actually occlusion percentage within a specific radius, others also take the distances to the occlusion into account.

So all the idea is just to make things look 'interesting'. it's not to make anything correct. if you had a couch on the floor in a room and you'd calculate AO, everything between couch and floor would turn out to be black mostly, but what if the only light source of the room is between floor and couch? the falloff of the light would look kinda inverse.

So there is really nothing physically correct, physically correct you would not darken corners everywhere http://nothings.org/gamedev/ssao/

The reason it was done in Crysis was because the alternative was to have a plain ambient color. Everything in sun looks incredibly nice shaded, plants have even back side lighting and then you step into shadowed areas at it would look like a quake level in the Radiant editor. switch it off and you'll see what I mean ;)


the right way to do sky lighting would be to actually do the whole light distribution (not just direct sky light, but all the bounces). baking that into a texture would give you at least the radiosity solution. (the rooms in the building would all get lit up to some degree). One step further is to save directional informations. e.g. directional radiosity maps like halflife 2 did back then http://www2.ati.com/developer/gdc/D3DTutorial10_Half-Life2_Shading.pdf
One step further would be to really save the hemisphere lighting per sample (could be vertex or texel of your map), that could be accomplished using spherical harmonics.
And yet another step further would be precomputed radiance transfer, that tries to save the amount of light per sample based on the direction of light, that way you could move the sun or rotate the objects. there are samples of PRT in older directX SDKs and you'll find quite some examples on youtube.

with physically based shading you'd need to integrate over the sample-hemisphere with your brdf per pixel (as, except for perfect lambert, brdfs are always view dependent). that would be a lot of data to push and also a lot of offline computation, but it would probably look damn sexy.

Share this post


Link to post
Share on other sites

I feel like it's a little unfair to just say that AO is fundamentally broken or not useful, even in the context of physically-based rendering. PBR in general is still full of approximations and weak assumptions, but the techniques are still useful and can produce more "correct" results compared to alternatives since they're still at least attempting to model real-world physical phenomena. A particularly relevent example is the geometry/shadowing term in microfacet BRDFs: it's been pointed out many times how they make the (incorrect) assumption that neighboring microfacets only occlude light instead of having light bounce off them, and yet it's still better than having no occlusion term at all. It's also a much more feasible solution compared to something crazy like path tracing at a microfacet level, so you can also just look at it as a reasonable trade-off given performance constraints. I feel like you can look at AO the same way: sure it makes assumptions that are usually wrong, but if used judiciously it could absolutely give you better results as opposed to not having it. For instance, representing occlusion from dynamic objects and characters. Sure you'd get better results if you simulated local light bouncing off those objects, but it's a heck of a lot cheaper to just try to capture their occlusion in AO form and can still be a lot better than having no occlusion whatsoever.

Share this post


Link to post
Share on other sites

Aye, ideally you'd path trace down to a microfacet level with the same number of samples as actual photons in the scene, with spectral response the whole way. But not even Hollywood does that. Approximations are needed, especially the more realtime you want to go.

 

There are plenty of hacks for ambient occlusion that are employed to make it closer to correct, bent normals are popular, and Crytek extend that to shadowing specular by the same amount as well: http://advances.realtimerendering.com/s2014/index.html#_RENDERING_TECHNIQUES_IN (The Ryse slides). Besides, GI appears to be a O(n) squared problem, so the number of bounces just grows your problem exponentially, and 3 bounces is considered minimum for a general scene to converge towards something appropriate. Considering no game has yet shipped with even a single proper short ranged bounce in realtime, I'd say approximations will be with us for the rest of this generation.

Edited by Frenetic Pony

Share this post


Link to post
Share on other sites

To show what it simulates here's a first rendering with a form of ambient occlusion :
50pc-diffuse-rasterizer.jpg

 

The ambient occlusion obscures an ambient cubemap (displayed color = aoterm * ambientcubemapcolor).

Then here's a simulation of the same scene using global illumination (path tracing) :
50pc-diffuse-path-tracing.jpg

 

The path tracing traces all possible rays between the eye/camera and the
light source (the primary light source in this scene are the Sun and the
Environment map which encompasses the sky but also the ground which
reflect a bit of light - of course in physical terms the sky and ground
are secondary and N-ary light sources, but the simulation doesn't
differentiate).

 

The rays are bouncing around, and there's a bit of inter-reflection in that second image but
overall the two images are pretty close. Not "exactly close" but you get
the idea.

 

To obtain the first image : sun contributes to direct lighting, is unaffected by ambient occlusion but has somewhat "hard shadows" (sun occupies a non zero area in the sky so in theory has a penumbra..). The rest (sky + ground) contributes to the ambient cubemap that is an average using the Lambert Diffuse model (a simplification) and that's multiplied by the AO term. The AO term is only a function of the surrounding geometry. Both Sun and rest are then added together to get the final color value.

 

 

as at face value ambient occlusion is creating light from nothing.

 

That's actually the opposite. Ambient *occlusion* as its name indicates occludes light source and so this effect substracts lights from the scene. It's an approximation of the real life occlusion of secondary light sources as shown in the two images above.

 

Maybe you meant : how to compute the ambient term (the ambient term adds light to a scene and is then multiplied by the AO term) ? Well it varies from game to game. Here I just did average the env map and stored it in a cube map. If there's fog and so on, it would also affect the env map to some extent so would naturally be factored in the resulting cube map. Some games will have light probes either baked at design time or calculated on the fly (if the light conditions are dynamic).

Early games did not have an ambient cubemap and instead had a simple ambient color (constant in all directions). Same idea except that you average everything to a single term and you lose some "detail" in the scene because the ambient light is no longer directional. They didn't use have to use light probes but the color would most likely be controlled directly by artists.
 

lambertian-model-direct-shadow-poster.pn

Here's a similar scene with a constant ambient term and no ambient occlusion.

Edited by LeGreg

Share this post


Link to post
Share on other sites

This topic is 1042 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this