Global Illumination alternatives

The_Distiller · April 21, 2015, 9:19pm

Thanks for that detailed breakdown!

Xerithas · April 21, 2015, 9:35pm

Always nice to hear updates about this kind of thing, even when half of it goes over my head there’s stuff to take away from it.

Looking forward to Heightfield GI as well =]

Frenetic_Pony · April 21, 2015, 9:44pm

Good to know! The 90m bounce distance for terrain specular doesn’t seem like enough, but then you’re tracing a 2.5d g-buffer representation, which is a heck of a lot like screenspace raytacing to begin with.

anonymous_user_fd738307 · April 22, 2015, 10:40am

DanielW;276486:

During the GDC demo (Dec-Mar) I did

GPU management of the distance field objects. Instead of the rendering thread uploading all the distance field objects every frame, the GPU manages adds / removes / updates. This allows many thousands of dynamic objects to exist in the scene and was key to supporting the scale of the GDC kite demo.

Support for instanced static meshes. The above GPU object management was necessary for this to be reasonably performant with trees. There were something like 2 million trees, these are culled down to just the ones near the camera very quickly.

Heightfield occlusion - provides DFAO from Landscapes

Distance Field GI prototype - Surfels (oriented disks) are placed on objects, lit by lights each frame to compute direct lighting (shadowing provided by distance field ray tracing), then compute GI transfer to pixels on your screen from all the nearby disks. Shadowing is provided from the same distance field cone traces as DFAO. Bounce distance is limited to ~10m, there’s some leaking, and it’s about 4x slower than it needs to be to run on mid spec PC / consoles. This was intended to be a general purpose GI method for the GDC open world demo that works on any static meshes but it wasn’t coming together fast enough so I shelved it in favor of heightfield GI.

Heightfield GI - provides GI from Landscapes, with a bounce distance of about 90m. Costs 2.6ms on 980GTX. This was done by creating a GBuffer atlas of the landscape components (diffuse, height, normal) then computing direct lighting for that, then computing the indirect lighting transfer to the pixels on your screen. It integrates with the DFAO pipeline to make use of adaptive shading and DF local occlusion. This is a pretty good feature for open world games and can still be optimized a lot (it was made in 2 weeks).

Then I took a month or so break in there to recover =)

Right now I’m revisiting DFAO, trying to improve the quality and performance so that it stands alone and can be used on consoles. I made 4x performance gains over the worst case by compositing all the per-object distance fields into a global one stored in clipmaps that follow the viewer and are updated incrementally. Then cone tracing only has to go through one volume texture instead of ~150. The quality is basically the same - I use the per-object distance fields for the beginning of a shadow cone trace where the self-shadowing is so crucial and the global DF for further out.

I also switched to computing DFAO at a fixed resolution based on the screen instead of the Irradiance Cache-like algorithm I was using before that did adaptive shading. The problem with adaptive shading is that it only helps in the best case - the worst case like foliage still has to do the cone traces at the high resolution, which kill performance. The result is more stable performance and less noise / splotchiness / shifting.

Once that is wrapped up, I plan to return to DFGI and fix up the major issues with it:

Multi-bounce GI. I want to solve this by computing shadowing in the hemisphere of a Surfel by cone tracing the distance fields, then storing off that directional shadowing representation. That will be used to shadow sky lighting (which will be come indirect sky lighting), direct lighting from other Surfels (which will become second bounce indirect lighting). This will be much faster now that I have a global distance field to sample.

Doesn’t work indoors due to over-occlusion. I want to solve this by combining the two shadow depth visibility functions - one from the pixel being lit, the other from the Surfel. Each visibility function has good quality near the point it is representing, but low quality elsewhere, so combined it makes the best of both worlds.

Insufficient bounce distance. With the combination of shadowing from both the receiver and the Surfels I can double the bounce distance without introducing a bunch more leaking.

Performance cost too high. Right now the Surfel lighting is very naive, culling only happens on an object granularity. I want to generate the Surfel tree using clustering so it is not object-based (light cuts), then I should get a big speedup.

Bright singularity artifacts. Having faster Surfel lighting via the better Surfel tree should hopefully allow the 4x higher Surfel density that is needed to improve these.

Anyway, that’s the plan. We’ll see how it actually pans out.

Wow this is much better than trello.
I always found that roadmap particularly lacking since team members don’t update the contents of the cards often, so i very much appreciate what you’re writing here.
Also, i find your propositions well thought, so i’m beginning to really hope on this. Especially on the speed increases. If we could reach the 8/10 ms with DFAO and DFGI even with their shortcomings i would be very happy.

mbullister · April 22, 2015, 5:10pm

Echoing what others have said, this is a really great write-up. Thank you.

Blue_man · April 23, 2015, 11:34am

I download zip file for the master branch and when I try to compile it get a bunch of errors.

Graute · April 23, 2015, 2:03pm

Did you say n when setup asked to overwrite files?

“edit”
Noticed the latest Master did not have any overwrites, so must be something else.

Blue_man · April 23, 2015, 2:21pm

I will post a picture soon.

Blue_man · April 23, 2015, 3:04pm

Graute · April 23, 2015, 3:52pm

I compiled the latest Master from 2h ago, and no errors.
Setup dependencies was huge, 19gb I think.

Blue_man · April 23, 2015, 4:18pm

I’m now downloading latest master branch.

Graute · April 23, 2015, 4:43pm

I cloned mine, perhaps the zip was older ver.

_cDub · April 23, 2015, 8:47pm

Out of all the possibilities in 4.8, DFGI is the one I am most excited for. A viable, non-performance intensive GI is going to be .

Blue_man · April 24, 2015, 3:05am

Me too.DFGI looks pretty good and it’s not that much performance heavy.

Sitrec · April 24, 2015, 6:26am

Same, it’s going to be a huge deal for our project (hopefully).

anonymous_user_d6e2ebc8 · April 24, 2015, 6:21pm

How will DFGI work in a mixed natural/city environment?

John_Alcatraz · April 24, 2015, 6:28pm

I agree, but Heightfield GI may be even more exiting :rolleyes:

Blue_man · April 24, 2015, 6:59pm

Does promoted branch have DFGI because master branch is crashing for me.

SonKim · April 25, 2015, 1:54pm

It ONLY works with terrain though! So not much use for a small city map.

, thanks for the update! Is the Distance Field GI base off this technique? http://http.download.nvidia.com/developer/SDK/Individual_Samples/DEMOS/OpenGL/src/dynamic_amb_occ/docs/214_gems2_ch14.pdf

Blue_man · April 25, 2015, 6:32pm

Can DFGI work with spotlight and pointlight?