Yesterday´s Master from early morning.
I´ll recompile latest for a check.
“edit”
It still works.
Yesterday´s Master from early morning.
I´ll recompile latest for a check.
“edit”
It still works.
Thanks for checking, Atle! There must be something specific to the setup of my projects then… odd stuff.
Have you tried to remove, then add movable skylight again or adjust distant fields settings in object editor?
Seem to remember this triggered DFAO that had disappeared even in editor.
Removing/adding skylight had no effect, but I believe you are right in that it must be one or more of objects (likely those placed with the foliage tool) that is causing it. So I’ll just have to try rebuilding a whole level from scratch (eek) & see if that doesn’t fix the issue. Thanks for your help, Atle!
Has anyone tried DFGI with lots of foliage? I ask because my lightmass time for even small maps is huge with a lot of foliage. As a single person developer it would be nice to just set it and forget it.
I´m using the Master branch, and have no problems with large forests, even with highpoly/texture assets from the kitedemo, getting interior lightning right is more challenging though.
It might be different on older hardware, since only tested on Titan/GTX 980 cards.
Is there a massive frame drop when you use more than a couple of interior lights?
Depends on the settings, but main problem is artifacts from distant fields AO/GI, but it´s not so obvious on textured surfaces.
I have DFGI turned off for foliage. (Why would you want it applied to foliage?)
I get decent fps and everything is dynamic in this scene
I am using distance field shadows, looks the same in and out of editor. Its necessary for my project but I am looking at AHR as an alternative.
Here is how my distance field shadows look in a high poly stress test (2.5 million Polys) with 1 distance shadow field at 70% resolution (1 dynamic light source for the scene).
Cause it should be applied to everything? At the very least the trees, I can see grass being overkill on fps for affecting GI, which is why I suggested just going for screenspace directional occlusion/raytraced reflections and calling that good enough. But ideally you’d have it affecting everything equally.
But I suppose since it’s not been updated the low sampling is still there for foliage getting contribution from DFGI. Which is why you just clump foliage/particles/etc. into boxes and take samples from the center.
Also, since the first paper I ever saw on surfels was for small scale ambient occlusion, is there any idea for using it for that as well? Dynamic ambient occlusion could be yet another improvement, and would have definitive benefits over SSAO, as the haloing, or nowadays (damned kids!) anti haloing artifacts around large depth discontinuities is pretty distracting.
The trello board for the ue4 roadmap under Dynamic GI it says R & D may not pan out. Will DFGI make it into a final ue4 build?
Why isnt anybody trying to implement this , i shouldnt be too difficult and even if isnt as acurate as something like voxel ray tracing , it looks nice , could be used in dynamic enviroments and is very fast.
Wow!!It looks great! How did you get this? DFGI or any other method?
It can’t be used in dynamic environments, because captured cubemap is static.
Ah the old sampling problems
Could the work on Multiple Importance Sampling that’s done in offline renders (like Modo’s new upcoming additions) solve this particular sampling problem?
Seems like the surfels sampling position could benefit from it.
https://graphics.stanford.edu/courses/cs348b-03/papers/veach-chapter9.pdf
Or maybe I’m just blabbering and I really don’t know what I’m talking about.
Besides, we already have that kind of system using spherical captures that push diffuse information on surfaces using a console command. Don’t remember which though maybe something on the lines of “r.diffuseFromCaptures = 1”, you need to search the forums I think someone has made a brief tutorial along with a discussion in another thread.
This doesn’t work properly though. The way it’s setup doesn’t make it an easy workflow choice.
Cube map are not inherently static , other game engines like unity can render them dynamically in an efficient way , because the rendering is distributed is distributed across several frames and you can even create scripts that makes them to only be rendered again when Unity - Manual: Reflection Probe
Can you further elaborate on this , do you mean that that cube maps have to be carefully placed in lighted areas , in that case , what can be done to improve this system , aside from better dynamic cubemaps , maybe automatic placement of them