The light leaks that occur with a stationary spot light come from application of the .1 StaticLightingLevelScale to photon settings. In particular, a ton more photons are emitted at StaticLightingLevelScale .1 and the search distance is decreased. This is supposed to increase the quality of the photon representation, but for some reason (I have not been able to determine) it results in a huge amount of variance / noise / splotchiness. This causes the phantom lights ‘light leaks’ in your images.
I simply disabled application of StaticLightingLevelScale to the photon settings in code. You can probably achieve the same workaround by increasing IndirectPhotonSearchDistance by 10x if you use StaticLightingLevelScale .1, effectively canceling out the scale. I have not tested this myself though.
StaticLightingLevelScale - this scales the density of every computation lightmass makes. It has two big noticeable impacts - for final gathering (which computes first bounce GI from lights + sky light direct) it increases the density of light gathers. It won’t actually increase the quality of light gathers, just how far apart they are on a surface. This improves shadows but explodes your build time. It also increases the density of photons emitted, this is what I disabled in my latest change to work around the phantom lights.
IndirectLightingQuality - this mostly increases the number of rays traced at each final gather, also known as NumHemisphereSamples in the ini. A value of 10 means 10x more rays and therefore 10x longer build time. You can think of more rays as a higher resolution image being resolved, so it improves the quality of light gathers.
IndirectLightingSmoothness - we filter between light gathers a bit to hide the last little bit of noise. The default amount of smoothing is quite high, so it can be useful to lower this to get more detailed shadows. Note that smaller values for StaticLightingLevelScale also decrease smoothness, so with a StaticLightingLevelScale of .1 you probably don’t need to reduce smoothing anymore. IndirectLightingSmoothness doesn’t affect build time.
I’ve made a test scene and played a little bit with skylight. I am really happy with the result.
Lightmass settings I used:
static lighting level scale 0.6
bounces 100
indirect lighting quality 10
smothness 0.8
This is a lot faster than anything I tested so far.
(Depending of the scene and without the futur “skylight portal”, the NumHemisphereSamplesScale may need to be increase even more)
PS : Please, can someone at Epic do something for the really ugly temporalAA implemeted in 4.9 (I try 4.10 preview and it’s the same thing).
Did you try to build lighting using high/medium quality?
I’m really curious to compare render time vs lighting quality, Rafareis got me curious since he bake everything usually using Medium lighting quality.
My 2c to or any developer working on this.
I was overwhelmed by the amount of settings that exist for lighting up a scene when I started digging into UE4. Rendering engines have moved on from the old hackish methods of lighting, to an easier and more modern approach, unbiased and physically based lighting. I dream one day that we have something similar in unreal. I know lighting in a game engine is wildly different from a ray tracer, but at least moving to that direction is what I’m proposing.
I’ve read through most posts in this thread and they always seem to be “Hey I tweaked this and I changed that and I don’t know what it is or what it’s supposed to do, but I got this awesome result.” We are all looking for the magic numbers that give us the best results, but I think I’m speaking for everyone when I say we desperately need to know why the numbers work and if we can do without changing parameters we don’t understand or are too technical.
Quite frankly, i wonder how have many good-looking games nailed the lighting with such huge number of settings and sparse documentation. UE4 is a great engine, the pricing model is a dream come true for an indie like me, but I feel this area needs some love and attention.
There are many settings because this engine can be used to make almost everything, from AAA games to small mobile games. It’s a jack of all trade engine. It’s nothing like an offline renderer specialized in architectural viz like Corona, for example.
The real thing is to learn how photon mapping works. I’m sure that more than half of us never ever read anything about photon mapping! That would be a great place to start ( posted a .pdf document about it in this thread).
I highly doubt Epic is going to change lightmass at all and afaik pretty much all engines use the same principles (photon mapping, lightmaps). I even think unreal is more user-friendly than it’s competitors!!!
A 1-click solution, easy to master, would be to use something like Lumion. But Unreal can do so much more than that, hence the complexity and the limitations of it’s ‘‘renderer’’ and the multitude of settings.
started this thread so we could sort out **problems that currently exist with GI ** - specifically with SpotLights and Skylights. In doing so, he has helped successfully (I think?) indentify ‘bugs’ and the issues we’re facing transitioning from our ArchViz workflow.
I dont think it’s really a thread for ‘workarounds’ or discussions on how to make it more user friendly for us. Perhaps it’s best to highlight those specific issues in a seperate thread and leaving this for resolving the issues highlighted by initially.
@ - Again thank you very much for explaining the working of those values (Post # 166).
I think we are nearly there to understand the internal workings of Lightmass (of course also waiting for Rafaeis123’s guide). As usual I have few more questions :rolleyes:.
I have created few visual notes of my general understanding about the working of values in BaseLightmass.ini, need your feedback about the same.
There is no difference at all after increasing the IndirectPhotonSearchDistance Value alone.
But Recently when and Koola Posted their results, they both were using “NumIrradianceCalculationPhotons” in collaboration with “IndirectPhotonSearchDistance”. Increasing “NumIrradianceCalculationPhotons” is certainly helping with light leaks a lot. Here are the results -
After increasing “IndirectPhotonSearchDistance” to a certain value say 1000, if we also increase the value of “NumIrradianceCalculationPhotons” by say 500 each time (I increased it from 1000 to 2000 in the tests), You sure can get rid of all the light leaks from the scene.
@anonymous_user_5867f9af - Kindly let us know if this is the perfect solution to remove light leaks (combination of “NumIrradianceCalculationPhotons” + “IndirectPhotonSearchDistance”)?
@ and @koola - Thanks for posting your results, I was finally able to remove the light leaks with help of “NumIrradianceCalculationPhotons” and “IndirectPhotonSearchDistance”.
Hi , thank you as well for putting all this together- I really appreciate all the great help and the other folks who contributed- very much appreciated
Awesome thread! I appreciate a lot all the contribution people are making.
@ (or anybody with that knowledge from post #8), if you could explain the functioning of Lightmass using Feynman Technique, surely most people would understand and we would progress a lot on this thread. Feynman Technique, for those who don’t know, is basically about simplifying a hard concept and making analogies as if you were explaining it to a 5 years old child.
Example:
For a 5 years old child, this would be very confusing:
“Gravity is described by the general theory of relativity as a consequence of the curvature of spacetime caused by the uneven distribution of mass/energy; and resulting in time dilation, where time lapses more slowly in strong gravitation”
But this would be easy:
“Gravity is what attracts the planets to the Sun and us to the Earth”
