Sign in to follow this  
B_old

Prebaked per vertex AO + deferred shading

Recommended Posts

B_old    689
I briefly considered adding pre-baked per vertex AO to static geometry. I'm currently using deferred shading. Am I right, that it would be wrong to apply the AO to the albedo color when it is stored in the G-Buffer? Because then the AO would be included in every light calculation. Instead it needs to be stored separately in the G-Buffer and only be applied in the ambient lighting pass. Is that right?

Share this post


Link to post
Share on other sites
MJP    19788
AO is an approximation in itself, so there's not necessarily a "right" and "wrong" way to use. However there are ways that make more sense than others.

Normal AO is essentially your total visibility to the sky about the hemisphere. Thus it makes more sense to apply it to things like a flat ambient term or an IBL diffuse term, since those aren't inherently directional. It probably makes less sense to apply it to a local light source, since those [i]are[/i] directional. For instance with AO a corner will be very dark, but if you aimed a a spot light at a corner it should actually be very bright. One thing you can do is store your AO in a basis that has directional information, like SH. This gives you a sort-of "directional AO" which encodes different occlusion values for different directs, which can give you a better approximation for both IBL lighting and local lighting (I believe Crytek does something like this now with their SSAO).

Share this post


Link to post
Share on other sites
B_old    689
Thanks for the suggestions!

I know this is off topic, but maybe you can/care to answer. What is the point of radiosity normal mapping? As the lightmaps are pre-computed, why isn't the normal mapped lighting calculation baked in there as well. I can only think of 2 possible answers:
[list][*]It would allow to change the normal maps after lighting calculation, but that does not really make sense, because changing the material would "invalidate" the pre computed lighting.[*]It allows to the keep the light map fairly low res, while still having high res normal mapped static lighting. (Is this even true?)[/list]

Share this post


Link to post
Share on other sites
MJP    19788
[quote name='B_old' timestamp='1313744608' post='4851115']
Thanks for the suggestions!

I know this is off topic, but maybe you can/care to answer. What is the point of radiosity normal mapping? As the lightmaps are pre-computed, why isn't the normal mapped lighting calculation baked in there as well. I can only think of 2 possible answers:
[list][*]It would allow to change the normal maps after lighting calculation, but that does not really make sense, because changing the material would "invalidate" the pre computed lighting.[*]It allows to the keep the light map fairly low res, while still having high res normal mapped static lighting. (Is this even true?)[/list][/quote]

It's the latter. Typically light maps have significantly lower texel density compared to normal maps...I think for Half Life 2 their luxels were around 4"x4". This is because a normal map can be tiled and reused many places throughout a level, while a light map has to be completely unique for all surfaces. So by encoding your lighting in a basis, you store not just irradiance for a single normal direction on a surface but rather an entire hemisphere of irradiance that you can query at runtime. This lets you get high-frequency lighting variation while still having low-resolution lightmaps (or even vertex lighting).

Share this post


Link to post
Share on other sites

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