The state of Distance Field GI in 4.8

Hey all, I see questions about this regularly so decided to get all of the info in one spot, since there’s no documentation yet.

The quick summary is that Distance Field GI is a prototype feature, it has a bunch of problems, and I recommend that you do not use it but wait for a better version. It is not expected to work with arbitrary content. This is why it’s not being announced anywhere - but observant people picked it up from github changes :slight_smile: Heightfield GI as used in the Kite demo is in a better state, but still not exposed in the UI and in a prototype stage.

However if you must continue…

Setting up Distance Field GI (bounce lighting from static meshes)

  • put r.DistanceFieldGI=1 in the [Startup] section of Engine\Config\ConsoleVariables.ini\ConsoleVariables.ini
  • Enable GenerateMeshDistanceFields in the project settings under Engine -> Renderer, restart editor (same for all distance field lighting)
  • Place a skylight, change Mobility to Movable. This is required even for GI at the moment.
  • Place a directional light, change Mobility to Movable

With and without DFGI in a simple scene
d79cb3b3eeca3e83ef2f61ce0afd06910b9a467f.jpeg2353831bdf390fce3e3dce15ddb34ef59abd02fc.jpeg

Check out the DFAO page for restrictions, in particular only static meshes, instanced static meshes (including foliage with opt-in bAffectDistanceFieldLighting) and landscape supported for bouncing lighting.

Limitations / Known issues

  • DX11 GPU required, and engine scalability settings must be on Epic
  • One bounce of diffuse GI from directional lights only for now
  • Bounce distance limited by the skylight’s MaxOcclusionDistance
  • Only static meshes can bounce lighting and occlude bounce lighting, but everything can receive
  • Lots of splotchy artifacts and overocclusion / leaking. Best results can be seen in mostly outdoor environments.

Troubleshooting

First, make sure DFAO is working properly with a movable skylight. Check that you are on Epic engine scalability settings. Use the Visualize ->DFGI mode and see if anything shows up there. Try in a simple scene with just static meshes.

Console variables for experimentation
r.VPLMeshGlobalIllumination=1
r.SurfelDensity=.05

Setting up Heightfield GI (bounce lighting from landscape)

This requires the same setup as DFGI, and then you need to add a Landscape. Some console variables that you can change at runtime, with their current defaults:

r.HeightfieldGlobalIllumination=1
r.HeightfieldInnerBounceDistance=3000
r.HeightfieldOuterBounceDistanceScale=3
r.HeightfieldTargetUnitsPerTexel=200

With and without heightfield GI in a simple scene
95e2212685b98076084339a349dc19fd0d11ad34.jpeg1BasicSceneNoGI.jpg

1 Like

Thanks for the info! I know this is a shot in the dark but would you be able to tell me whether DFGI is “piggybacking” on top of DFAO or is it a significant performance hit in and on itself?

More importantly, do you know if the final, theoretical and fully optimized version will work on the PS4 without melting it?

Is the DFGI supported by Mac OS?!

DFGI reuses the occlusion cone traces from DFAO and the upsampling pipeline, but has some cost in itself. Right now that cost is very high as it’s brute force gathering 100k nearby surfel lights.

That’s the goal that we’re working toward, but no I don’t know for sure. However, we have some pretty big optimizations for DFAO that get it down to ~4ms on PS4 in large game scenes (Fortnite and Kite Demo). These won’t make it into 4.8.

Sorry, only PC D3D11 and PS4 are supported at the moment. Mac OS has very poor OpenGL drivers which restricts us to OpenGL 3.2 capabilities, which corresponds with D3D 10 (regardless of the features that the hardware itself supports).

This made my day! Thanks a ton!

So why would we use these techniques vs CSM? Also, as I understand it, you used CSM for close shadows and HFGI for distant shadows in the Kite Demo, and from my understanding the reasoning was that HFGI doesn’t support vertex animation (aka foliage animation) while CMS does. How does DFGI fit into all this then? What is an example of a place where I would want to use DFGI over CSM/HFGI? Also, would you want to combo DFGI with CSM or HFGI for some things? It’s pretty confusing because we have three different dynamic shadowing techniques, and while the differences between them make sense for the most part, I still fail to grasp what circumstances are best for each use case and how (if ever) to combo them properly for different use cases.

If you want a specific example, how about a primarily-outdoor fairly large jungle-y scene with man-made structures built in, that supports dynamic Time-of-Day? My gut instinct is to say that you would use CSM up close and HFGI for distance shadowing, but what would you do then for interior lighting, particularly if it needs to be turned off during the day and on at night?

Sorry for the lengthiness of the post, and I hope you can help me out with grasping these different techniques and their use-cases.

Thanks a ton!!

Thanks for the info mate. Will be watching :smiley:

Thanks , nice to have this summarized.

Thanks for the thread !

PS: Hope you don’t mind, I’ve temporarily stickied this since I think I’m going to be directing people to it an awful lot…

Thanks,nice overview of the gi.

You are mixing up terminology a bunch =)

GI techniques (DFGI, heightfield GI) are for solving bounce lighting, while shadowing techniques (CSM, Ray Traced DF shadows) are for solving direct shadowing.

Direct shadowing recommendations for an outdoor scene:

  • Use Cascaded Shadow Maps up to about 20k units (200m). This allows World Position Offset animation and high resolution near the viewer, but it will be very expensive.
  • Use Ray Traced Distance Field shadows from 20k units to 100k. These tend to be more efficient when many triangles would have been required, as is the case with many distant trees. However, RTDF shadows don’t support landscape so you need a 3rd method:
  • Use Far shadows (FarShadowCascadeCount) for 20k to 1000k. These are just CSM that only include tagged objects with bCastFarShadow set, so the GPU cost is low. By default Landscape will be the only thing included. Note that this overlaps with the RTDF shadow range.

That’s what we did for the Kite demo. It’s a bit of a mess with the far cascades in there, but that’s what we have for now.

With the upcoming (post 4.8) optimizations for DFAO combined with heightfield GI, I think we will be in a great spot for outdoor scenes with fully dynamic lighting. Indoor lighting however needs a lot of work.

Thanks for the write-up !

DFAO and heightfield GI work so amazingly well for outdoor environments!

Do you think you can get the splotchy artifacts to a minimum for DFGI? I know it’s still very early days, just curious about that particular aspect.

I hope I might get your advice / suggestion on a few aspects regarding scene lighting and outdoor scenes in general.

  1. What is a good size for a streamed level? 50 square meters (Skyrim size), 1 kilometer?

  2. Is there any good way to transition to fully indoor scenes right now? Since everything is streamed we need to get rid of the skylight when entering but with a door and an animation that opens together with some clever camera cuts will be enough to help with that.

What I am more curious is whether we can do lightmass on only those full interior levels? Will their maps stream in together with the level?

Thanks for the clarification! So that means the Kite Demo didn’t even use GI right? Wow…it looks really good considering, guess the skylight helped a lot in that regard?

That said, for the future, while these GI methods get optimized, what do you think would be the best setup for a scene like I described in my last post?

Thanks again!!

Hi ,

Will the Xbox One be supported in future? I thought the Consoles share a pretty close to each other GPU.

That’s actually the area they differ the most. The consoles have nearly identical CPU’s, but the PS4 uses GDDR5 memory and has a GPU that has about 25% more raw power (don’t quote me on that, cause I can’t be 100% sure, but I think it’s close to it).

I can’t say with confidence yet. Some of the splotchy has been improved in my latest (not yet checked in) DFAO changes, which also affect DFGI. However, some of the splotchy is inherent to the technique. It remains to be seen. For sure the current level is unusable indoors though.

It depends on what you want your streaming granularity to be. You can have a look at what we used for the Kite demo, that uses streaming for the interactive portion, distant areas are represented by a baked down mesh.

If you use a Stationary skylight, it will be shadowed indoors and ‘just work’. This requires you to bake lighting though. Otherwise with a movable skylight you could just fade it out (ramp intensity toward 0) as the player is going indoors. When you look back outside it will look wrong.

I would go with heightfield GI (once it is considered usable) + DFAO on skylight. Indoors regions will have leaking though from the heightfield GI + DFAO shadowed skylight. It’s very difficult if not impossible to make a dynamic GI method that both performs well and does not leak =) Indoors can otherwise use local point and spot lights.

No, Kite demo used Heightfield GI + Skylight shadowed by DFAO.

Deer valley with and without heightfield GI

DFGI is pretty rough right now, but HFGI honestly seems to be quite usable. In future versions, is it possible that one could be officially released before the other?

The Kite demo used Heightfield GI. It’s just that only the Landscape could bounce light, none of the static meshes or foliage. For an entirely outdoor environment that worked pretty well.