Nope, I am not^^
1-GI means Global Illumination, it means that the light bounces after it hits a surface, like sunlight coming through a window illuminates the entire room to some degree because it bounces off the floor. Baked lighting in UE4 already does this, but it takes a lot of processing power so getting something that gives a similar effect with dynamic lighting is a new feature that many people would like.
2-Direct lighting would be like where on the floor the sun hits first, and then indirect would be the illumination from the bounces after that
3-HDR is high dynamic range, a computer usually controls color on a range of 0-255, which is limiting because for instance something that is white would be the same value as something that’s very bright. HDR can store that information on a higher range, so that something that is bright would be higher than a 1.0 value
PBR is physically based in how it shades the materials, and how it controls energy values, it controls things like reflections and diffuse colors so that they look accurate
4-PBR should be similar across engines, since it’s based off physically accurate values, but UE4 has the added benefit of more realistic reflections (reflection probes, SSR) and the material editor in UE4 is way way way better than any other material system in a game engine. The shaders in Unity are strict, if you want to use a texture in a different way, you have to write a new shader. With static lighting, UE4 is best, it just does a better job than Unity.
Dynamic lighting----Enlighting gives dynamic GI at a high quality, but it only works with meshes that aren’t moving, the lights can move but the objects can’t. Plus, there’s some preprocessing that has to be done, where the system creates low-poly meshes of everything that it uses for lighting.
In UE4, Distance Field GI is more flexible (it can be used with animated objects and it will support deformable objects at some point) and it’s also faster, though not as good results. There’s also a little bit of preprocessing involved since you have to calculate distance fields for each object.
There’s also VXGI option for UE4 now, which is Nvidia’s dynamic GI system, the benefits are that it gives better quality than DFGI, supports everything, and there’s no preprocessing involved. The downside of VXGI is that it’s slower so it needs more powerful graphics cards.
I like where this is going! Keep it up!
I have a couple questions about the current implementation of DFAO / DFGI, given that it seems to be the main direction the engine is heading for realtime lighting (LPV isn’t getting much love)
1 - How suitable will DFGI ever be for interior scenes, given that the key light is currently cast from a movable skylight? Can other lights in a scene, for example if you had a spot light in the centre of a room, contribute?
2 - Given that it’s a DX11 feature, how does the engine handle fallback to a non-supported computer?
Sorry if this sound completely noob, but you’re talkin too pro in here and just got me wondering:
Right now as of 4.7, for a full project (i mean not just tests but a project that will someday become a full game xD) which system is best recommended? DFGI or the old LPVGI or any other approach i may have missed?
Sorry if this is a question that shouldn’t be here.
A few posts back said it won’t be included until 4.8 and then it will be disabled by default until the performance/quality/features are all up to standards which I would expect will be several release cycles from now–the graphics guys need some time to sleep too. Right now in 4.7 your only options would be LPV, baked static GI, or direct lighting.
Given my small knowledge about this, i would say it depends of what kind of game :
- If it is a game with relatively small outdoors (really most games) then it would definitly still be Lighmass GI by now.
- If your game is mostly outdoors then you should consider some non-baked Global Illumination between LPV/DFGI because Lightmass GI become extremely RAM hungry on very big levels.
- I would never advise VXGI because it will likely need a killer Nvidia graphic card for a while.
- And for android games, then direct lighting?
As for me i’m only interested about GI because i’m lazy to learn how to make all these UV ***** works correctly…so i prefer to dump on graphic quality and framerate to gain large amounts of time for really fastly done real time ArchViz
Thanks both for your answers!
Well in my game i’ll need dynamic light cuz it’ll include day-night.
Is a vast world too (i probably could call it open-world but maybe it’s not exactly that :P), it’ll have more outdoor than indoor probably but still it’ll have both. So i can assume LPV will work cool for an “open-world” kind of game?
@Jacky, thanks, I must’ve skipped over that post or something. Although I’m still unsure how the engine handles a fall-back in case of a lower-end GPU.
LPV would work for that, but DFAO/DFGI seems to be the more supported implementation.
Sorry if i put this here, but since i started learning ue4, and now reading this thread i’m lost with all the GI solutions.
Simply, when i launch the 1st person template, and hit Build, what method do i use? Lightmass GI? (Here when it goes over my available Ram, the comp freezes)
I’m reading a lot about every aspect of the engine, but could someone summarize what are the differences between Lightmass GI, LPV, DFGI, VXGI, where are they, when/why should i use one or the other? Are they dependant on the used lights types (static/movable)?
Thanks in advance
but DFGI is not available in 4.7 isn’t it?
And version available in 4.8 won’t be ready to release.
If you want to use dynamic GI you have accept that DFGI is currently WIP part of engine. Work on other parts of your project, having in mind DFGI is coming. Forget about LPV - it’s limited implementation and I doubt Epic will develop it in foreseeable future.
- Lightmass GI - static GI with extremely beautiful results. Pros - you bake GI on developer PC and end users(players) CPU/GPU don’t have to calculate this part of rendering, it’s pre-baked and will work very efficiently. Cons - it static. If you move any object - GI is broken.
- LPV - dynamic GI with good results. Pros - it’s fully dynamic, you can move lights and objects without breaking GI. Cons - it’s unoptimized and very heavy on players PC, a lot of light leaking with thin meshes, thin spaces and etc. Afaik it’s “frozen” project for now.
- DFGI - dynamic GI with good results.Pros - It’s fully dynamic, do light leaks, works good with any meshes and more customizable in terms of performance. Cons - it’s currently in development and not finished by any means. A lot of optimization work should be done and some bug fixing, but if everything work out - we will get superb GI that works good in outdoors scene AND in indoors!
- VXGI - dynamig GI with more than good results, but works on top nvidia cards only(Not 100% sure though) and very-very costly.
Thanks for your explanation, very clear, but to be sure:
So by default in 4.7, Build = Lightmass?
DFGI as the next proprietary GI solution, already available in 4.7 in experimental mode, and in normal mode in 4.8?
Not exactly, it is **static **GI solution, so in next versions it won’t be replaced by DFGI. It’s like different tools for different tasks.
DFGI is next **dynamic ** proprietary GI solution. Afaik in 4.7 it’s disabled and you won’t get access to it before 4.8(Well, if you don’t use ofc)
Thank you!
I finally found out why i was “unable” to see any difference between putting rDistanceFieldGI=1 in my conf file or not!
First, i did not knew i could check it with Show->Visualize->Distance Field Global Illumination.
Then, i had two directional lights in my scene (well…it was nicer with it lol) and the GI is totally ignoring my second directional light which is by far the strongest and so it was very hard to notice any difference between with GI or not!
About VXGI, for now it has many bugs and lacking features like emissive materaisl aren’t part of their GI system for now, the same for indirect specular. Also VXGI is programmed to only have one bounce level which is not eneough for many scenes since some areas don’t get lit by just one bounce thus the lack of many needed results like indirect refelctions.
Does DFGI work interiors for the time being? How many bounces does it have (I hope at least two to be reasonable)? Will it be available to to 4.8 preview when it comes to launcher? Thanks !
]
About VXGI, for now it has many bugs and lacking features like emissive materaisl aren’t part of their GI system for now, the same for indirect specular. Also VXGI is programmed to only have one bounce level which is not eneough for many scenes since some areas don’t get lit by just one bounce thus the lack of many needed results like indirect refelctions.
Does DFGI work interiors for the time being? How many bounces does it have (I hope at least two to be reasonable)? Will it be available to to 4.8 preview when it comes to launcher? Thanks !
[/QUOTE]
I can answer this for you:
VXGI emissive:
DFGI emissive:
Although DFGI may have a significantly greater performance now compared to VXGI, this is the level of quality you will get if you look closely.
I’m not sure how the quality of DFGI can be improved in the future whilst still having a competitive performance to VXGI - simply because VXGI uses Hardware Filtering which comes naturally from using a 3D Texture. Whereas, it seems that DFGI has to be filtered manually. Then again, DF shadows seem to be really good quality (not sure how its done yet) whereas the quality of voxel based shadows are heavily dependent on the voxel resolution.
DFGI is also only capable of diffuse reflections (not specular).
DFGI currently only has a single bounce as well.
I discovered from the 4.7 release that it now works for point lights and spotlights.
So I just had a look at the DFGI code. I noticed that it samples the SceneColor texture - i.e. this texture has both direct and indirect lighting composited. Correct me if I am wrong, but technically in every following frame, it should sample the indirect lighting which is added to the texture, thus creating multiple bounces. But something seems to be stopping it from doing that. I’m thinking it may be because it is in screen-space thus areas which cannot be seen cannot contribute to a bounce. However, a scene should exhibit color bleeding when only an emissive object is active (with no other lights) - yet it doesn’t.