Using Shadow + GI lightmaps in a PBR pipeline

Started by
2 comments, last by MJP 7 years, 1 month ago

Thanks to help I got here, I've now got a light mapping system that can generate nice looking shadows and global illumination. However, I'm a little confused on how to effectively use the results in my rendering pipeline. Should I separate the shadow map and GI map (maybe put shadow mask the alpha component) so that I can still get dynamic specular highlights for the precomputed light source, but only on the directly lit areas? Is there a more effective way of achieving that that I'm not thinking of? Is there anything specific to PBR (energy conservation, combining with environment maps) that I should keep in mind?

Thanks

Advertisement

Yeah generally precomputed direct lightmaps are separated into channels so you can get dynamic specular. You can thus have up to 4 overlapping lights with pre-computed lightmap shadows (4 channel target). There are various other ways to store precomputed direct shadows today, ones that can include depth information so they work just like shadow maps. The one I was going to link to was free, but is now paywalled. So if anyone else knows a free one as such...

You could bake specular as well if you store directional enviroment information in the lightmaps too (summary in MJPs blogs about spherical gaussians).
Due to memory cost this works only for rough materials, but most real world materials are rough.

Sharp reflections may additionally need something like sparse but higher resolution reflection probes, SSR...

Notice you can also bake the backside of surfaces to get things like subsurface scattering.
And of course this enables normal maps at higher resolutions than lightmaps (otherwise you'd need something like a main light direction to fake it at least).

I can't say much for the problem of dynamic objects blocking precomputed light.
Most games simply ignore this and add some dynamic lights on top to get a trade off.


I'm not sure what you guys exactly mean with seperating GI and shadows or precomputed shadows, but beware of anything that limits yourself to use point lights only.
Using precomputed GI means you can get area lights for free so i'd use them heavily because point lights are ugly and unnatural.
Similar to using one bounce vs. multiple bounces this may have a very bad effect on the beauty you get out of precomputed lighing.

These days it's common to only bake the indirect contribution from analytical light sources. This way you can handle the direct lighting with standard deferred or forward rendering, and apply dynamic shadows using shadow maps or the technique of your choice. In our engine we expose settings on our lights that let the lighting artist choose whether to only bake indirect lighting, or bake indirect + direct. For some cases (for instance, where the light only touches static background geometry) they will completely bake the light so that there's no runtime cost. But for most lights in the foreground they will only bake indirect, and the engine will compute dynamic shadows and diffuse + specular per-pixel.

We also bake shadows for some lights, but we store that in a separate texture. We'll usually use these for areas that are further away from the camera to save on performance.

In terms of energy conservation and making sure that your baked lighting combines properly with other light sources, just take the time to think about exactly what you're storing in the light map and make sure you're not "doubling up" on anything. So if you're just storing indirect diffuse lighting, then adding indirect specular lighting from a cubemap is totally fine. If you need to, try writing out all of your sources onto a piece of paper and figure out which parts correspond to the rendering equation and your BRDF('s). This can help for making sure that you have the proper scaling terms (like 1/Pi for a Lambertian BRDF) and also for keeping track of which radiometric quantity is stored in your lightmap.

This topic is closed to new replies.

Advertisement