ultimate lightmass tweaking

There is a lot of informations spread out on this forum about lightmass settings but I would like to have opinions about what’s the general consensus/methods to achieve the best results in a decent amount of time.
Sometimes I tweak stuff without knowing exactly what is the interrelation between different settings. It’s hard to make all the test by myself because building the lighting often take many many hours!!! My pc almost exploded this morning trying to build my lighting and was still stuck at 0% after 2 hours. (it was still collecting photons)

General Lightmass settings include :

Static level scale (def 1) : I use .4 to .8
Number of bounces (def 3) : I use 100 bounces
indirect lighting quality (def 1) : I use between 3 and 10 here!
smoothness (def 1) : I use .4 to .8

Then there’s the baselightmass.ini :

this is koola’s settings (I use normal production settings for now)


Then there is the lightmaps compression : (I still use compressed lightmaps)

My question is, what part of these settings have the biggest impact on quality? is it the lightmass settings, is it the ini settings, is it both?
Are my settings overkill? It’s for arch viz (can’t have blotches and bad shadows and it’s for relatively small scenes). Please post your setup and discoveries about lightmass! The appeal of UE4 for architectural visualisation is that you cut render times. But if lightmass is going to take 3 days to compute lightmaps…meh we’re still gonna need a render farm lol!

pc specs :

core i7 2600 3.4ghz
gtx 980 sc
8gb ram (soon more)
2 x SSD
win 8.1
ue4 4.7.3

I can’t really help that much, but one thing I’m wondering (something that I’ve seen other do as well) is why you’re setting the number of bounces to 100? Light never bounces that much IRL. It’s extremely rare that light bounces more than 15-16 times.
When I do photorealistic rendering, I usually find that 10-12 bounces is more than enough, unless you have loads of transparent reflective materials that makes the light bounce around a lot, but even then, I’ve never needed more than 16 bounces.

As for indirect lighting quality, that is a factor that affects calculation time a LOT (it even says so in the tooltip). I’ve never had to use more than 4 here, and 2-3 is usually enough.
Oh btw, the Static Level Scale is supposed to be changed if your scene is in a different scale than UE units (cm as default), so to get proper shadowing this should usually be set to 1.

Light bounces for infinity, if the light source is bright enough. By that I mean there is no direct number of bounces for light in real life. It has a natural falloff based on the light source brightness. 100 bounces gives you that since it will only bounce as many times as it needs. It also doesn’t affect build times to have it set to 100, so why not?

Ok then at least it does not impact build time too much!

Yes, theoretically light can bounce infinitely, but for pratical purposes it never does. And we’re talking practical purposes here, not theoretical.
Are you sure that UE detects how many bounces are needed, and doesn’t do more calculations than that? I have no idea, but if you’re right there’s no harm in setting it to 100.

EDIT: I see in the tooltip for the number of bounces that “successive bounces don’t really affect build times” so that means that 100 is not a problem.

Here is a basic example set up to demonstrate this as well:

Photon mapping handles a large number of bounces very well, so there’s not much extra build time cost to increasing the bounce count. The only place I’ve seen higher numbers like 10 matter is indoors with very bright walls (.9 or higher base color) where the bounced light does not get attenuated much on each bounce. Otherwise it tends to have no visible result for more bounces than 5.

As for the ini settings vs UI settings, we try to make the UI settings have the same results as tweaked ini settings but with much more intuitive settings. In other words, you should not have to tweak inis to get best results.

IndirectLightingQuality scales many of the things that are scaled up in Koola’s ini settings. In particular, it will increase the base resolution of the adaptive solver (how many rays are initially traced in the final gather, NumHemisphereSamples) and then it will also increase the maximum adaptive depth (how closely we look in one direction where brightness differences are found, NumAdaptiveRefinementLevels and AdaptiveBrightnessThresholdScale). Increasing this will of course explode build times.

IndirectLightingScale controls the size of the shadow details that Lightmass tries to solve. This was originally intended to speedup lighting in large levels where you are just flying through and not looking at the details. I haven’t tested with values smaller than 1 much but I’ve seen guys like Koola get good results. The main thing that can be improved here is that Lightmass will compute indirect lighting at a finer granularity with smaller IndirectLightingScales instead of just interpolating it from neighbors through Irradiance Caching.

**IndirectLightingSmoothness **is just a crutch to hide noise with filtering. You should always go as low as you can without having splotchy artifacts. Detail indirect shadows (eg where table legs meet the floor) will disappear due to smoothing otherwise.

Thank you guys, really appreciate the fast support! Epic FTW!

I’d like to know if there is a huge quality difference between using compressed vs uncompressed lightmaps…

The difference is noticeable if you have surfaces that have relatively flat colours and aren’t detailed enough to hide the compression artifacts of the compressed lightmaps.

Ok thanks!

Basically, if you have a super clean Mirrors Edge like art style, compression artifacts will show up. But if you have a level with with some texture to it, the artifacts will be easily hidden.

Hi guys, have any difference in “.ini” Baselightmass between 4.10 and 4.11?