Jump to content
  • Advertisement
Sign in to follow this  
joeblack

DX11 Dynamic ibl

Recommended Posts

Hi guys,

i implemented ibl in my engine. Currently i precompute cubemaps offline and use them in game. This works good, but its only static. I would like to implement dynamic cubemap creation and convolution. I more or less know how to do it. But : My current workflow is : Render hdr cubemap in 3dsmax with mental ray (white material for everything). Convolute with ibl baker. Use it in game. Capture probe ingame (only once). Convolute with ibl baker and use it without changing. This is used for every "ambient" light in game. On top of that I'm rendering "normal" light (with ambient and specular).

I would like to capture and convolute cubemaps dynamically in game. So capture cubemap in 3ds max once. Use It in game and generate cube maps there at some time. This sounds easy. But as I said I first render ambient lights and on top of that normal lights. Then I create cubemap from that and use it in next frame for ambient light and add normal lights... Creating infinite feedback. Is there any way around it ? I believe games are using reatime generated ibl cubemaps. Or it's done completely differently ?

Share this post


Link to post
Share on other sites
Advertisement
3 hours ago, joeblack said:

Creating infinite feedback.

The feedback loop is actually just "bounce lighting". As long as your materials obey the physical rule of conservation of energy, it will be ok. Every time through the loop, most of the energy gets lost, and exponentially more and more gets lost every iteration. 

Share this post


Link to post
Share on other sites
6 hours ago, Hodgman said:

The feedback loop is actually just "bounce lighting". As long as your materials obey the physical rule of conservation of energy, it will be ok. Every time through the loop, most of the energy gets lost, and exponentially more and more gets lost every iteration. 

Not really, this leads into the "local lighting" infinite bounce trap. Light won't "travel" throughout the level correctly unless you iterate over every single cubemap therein, which you don't really want to do. So you end up with pockets of extreme brightness where the light bounces around next to ones of extreme darkness. You also have iteration time lag, so when you start it's very dark and the longer you hang around the brighter (though less exponentially) it gets as each iteration bounces more light. Still, it can be very annoying looking, as there's a literal "lag" to light and it's travelling very slowly somehow.

The general idea is doable however! The only full shipped version I'm aware of is Call of Duty Infinite Warfare with their Fast filtering of reflection probes and the Rendering part. There's several strategies you could choose from, but all of them ditch the idea of taking the previous cubemap lighting results and re-applying them infinitely and recursively.

One is only using local and sun light for lighting each probe at runtime. You'd only get one "bounce" but you could render and ambient light as well. Another is rendering the ambient term into the reflection probes, then just using the reflection probes for the final pass and no ambient there. But this can lead to odd colorbleeding results that don't look good.

A hack could be as so: Light your cubemap with an ambient term, take the resulting hdr cubemap and re-light the original, unlit cubemap with it once. This should provide an approximation of multiple light bounces and smooth out any weird color/lightbleeding artifacts that come from doing only one "ambient" bounce. As long as you smoothly blend between cubemaps for both spec/diffuse I'd suspect there wouldn't be much "boundary" artefacts where inappropriate dramatic lighting changes happen.

That being said check out the rendering parts separate spherical harmonic ambient occlusion like term. The idea is to take a higher resolution, precomputed sample of global illumination results. And then where that differs from the sparser cubemap information bake the difference into a greyscale spherical harmonic, so naturally dark areas don't get lit up inappropriately because the cubemap isn't correct, and vice versa. It's a hack, but an effective one.

Edit  - The Witcher 3 also does some sort of dynamic cubemap thing. But I'm not entirely sure how it works and I don't think they ever said.

Edited by FreneticPonE

Share this post


Link to post
Share on other sites

Hi Hodgman ,

after I implemented it, it looks quite good actually, you were right. Im using NdL/PI for diffuse and GGX from internet for specular. For 128 samples its also quite fast. I needed to rewrite my camera culling code a bit to make it usable.

 

Thanks again.

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  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!