why DFGI look like this for me http://i.imgur.com/QTYs7ef.jpg?1
Same here, i really loved to work with LPV and wanted to give DFGI a shot. For LPV we had a good base of options to work with, using the Post Process Volume.
Do we have any options yet to tweak, even if DFGI is not meant to be used for production yet?
My results with one skylight and one directional light - i don’t think i got the right results there.
The only thing that really bothers me are the big splotches - trying to find an option to increase the resolution. Any ideas?
Greetings, Toby
#Update: Oh, first post. I apologize not introducing myself. Tobias aka Kajisan, 32 - Senior 3D Artist, coming from movie-business - working on games now.
Longtime reader on the forums but never wrote something yet. Good community 
you can change resolution here http://i.imgur.com/2BHu0ry.png?1 http://i.imgur.com/TPFTF1w.png?1
Oh! Totally missed that one. Thank you!
The surface of the scene is represented as Surfels / disks with DFGI so the methods have that in common. But indirect occlusion (which is by far the harder part) is provided by distance field cone tracing, which is a totally different approach than the Nvidia one, which uses the same disks for occlusion. You have to have 10x or 100x times more disks than DFGI uses to also use them for occlusion, and it scales really poorly with surface area. Just think - how many disks does it take to represent a ground plane?
Hard for me to say, but it looks like maybe you’re still on 4.7? DFGI is NOT in 4.7, but I stupidly had something hooked up to the ‘r.distancefieldgi’ cvar so now whenever someone tries that in 4.7 they think it’s DFGI. Lesson learned.
Honestly I think you guys should just wait, DFGI is still early and has lots of problems, that’s why I’m working on it. You may notice it has not been announced anywhere, there’s a reason for that.
If you want hidden tweakables, all the cvars are under ‘r.ao*’ for DFAO related stuff (sampling rate, etc) and ‘r.dfgi*’ for GI. The main ones for DFGI quality are the Surfel density and the bounce distance. I can’t remember what the cvars were atm. You probably have to reload the level after changing those, as Surfels are generated on load right now.
Not yet, planned though.
I am using 4.8 but thanks for reply http://i.imgur.com/mqwvLa6.png?1
I think I know what the problem is,I scaled up my model.
Anyone have a clue what’s causing the flickering/missing “band” of shadowing with DFGI?
It seems like there is a certain distance from the camera from which the shadowing just “stops”?
I see a lot of artifacts in the video which are caused by extremely bad compression, so if you want to show flickering or whatever you should create a better video.
Ah, yeah, sorry about that. Vimeo isn’t my friend just quite yet. Here’s a still that illustrates my issue.
I did some testing with LPV,DFGI and Lightmass.What do you think?
LPV: http://i.imgur.com/FLh7JTN.png?1
DFGI: http://i.imgur.com/jruZBgk.png?1
Lightmass: http://i.imgur.com/AjlXjez.png?1
I wonder why the cube on the right received green light with DFGI, the wall is orange :eek:
Lightmass is the best.
It seems like lightmass is softer while lpv has better color bleed, dfgi is playing mind games.
I got some good looking results with lpv. http://i.imgur.com/hsFGRJK.jpg?1
I probably did something wrong with dfgi. 
As one can see, all GI methods, even pre-computed, have big problems today. Low resolution, problems with dynamic objects, etc. etc. And unfortunately with the GPUs the console makers decided to go with there’s not really enough performance there to just brute force some of the better solutions researched today. So ending up with something, anything, dynamic and useable at the same time is going to be a huge win.
Personally I love the idea of the heightmap GI. Storing a g-buffer of the albedo/inputs and sampling an output buffer of say, HDR10-10-10-2 via something like cone tracing should be relatively doable. And I say cone tracing because you’re cone tracing a 2.5d heightfield you can easily mipmap and assume that there’s no gaps in. It’s also trivially shadowed and lit from a single directional light source, as something like CD Projekt Red’s terrain shadows (just shadow from the heightfield) and cloud shadows can be projected onto the terrain. One can also include anything “big” enough onto the g-buffer if one wants. Large buildings/forests might be able to be included.
This also works well for distant shadowing. If you take the top of a forest of trees into account for some distant part of the heightfield, but sample from below the trees in the scene, you can account for a hacky/distant occlusion between the two and keep some more obvious “popping” from happening relatively cheaply, allowing one to limit the distance DFAO needs to be calculated.
This looks pretty promising: https://youtu.be/j-t_lDGKTh8
Can this somehow be implemented into Unreal engine 4
DFGI is the best and correct result among the three. LPV seem to be simply broken and lightmass seems to have alittle issue with the wall to the left (green) .
Thanks for the test mate.