Ok so here is an apples to apples comparison of ****** Mod **and the 4.18 preview. Skylight only, using an HDRI and 15 light bounces. Static lighting scale of 0.1
ini was modified on both : NumShadowRaysScale=**16 , **NumPenumbraShadowRaysScale=**64 , **NumHemisphereSamplesScale=**32
's build is much faster, but I feel that 's modded version looks a bit nicer. There is a big difference in brightness although I imagine that Daniels build might play better with sun lighting.
While working on multibounce in 4.18 I compared vs 's implementation and found the results to be nearly identical (screenshots attached). However, 4.18 also has a filtered cubemap representation for the skylight which causes significant differences, which are expected. I think the difference you are showing is actually from the filtered skylight.
You must set bUseFilteredCubemapForSkylight=false in BaseLightmass.ini to compare 4.18 multibounce to 's to get apples to apples.
Thanks for the response and great work! Apples to Apples indeed!
With further testing I was able to replicate almost similar results than 's modded version by setting “bUseFilteredCubemapForSkylight=false” in 4.18; although there are some differences with 's build providing better quality and speed.
Taking into consideration that the cube map was filtered actually provides more accurate results, so I chose a camera angle that better illustrated what using an HDRI should look like.
Yet the Default version is actually very nice and represents exactly what a HDRI light scene should look like.
Seeing as we can get very different results from a filtered and non filtered version it would be great to be able to switch between the two in the editor directly!
Very impressive work with the new lightmass. I thought Luochang’s Lightmass was good but this is even nicer.
I’m one of those people who like to find a good setting for things and then don’t feel any need to experiment with them. Would the “standard” 4.18 Lightmass give me the most correct result (without changing the lightmass.ini) or would that be different from case to case?
Just use the stock one. When and me were working together we used some offline renderer (Mitsuba Renderer) as reference and it showed very similar results. The only thing you may want to tweak is the option I mentioned at #222 if you have tons of memory and want to make it faster. Basically when bUseFilteredCubemapForSkylight is turned off it doesn’t mean using a non-filtered cubemap, but not using a cubemap at all (it will use a super blurry SH representation of skylight which loses most of directionality and is not physically correct). So unless you want to intentionally make the environment lighting more ‘averaged out’, you probably never need that option.
Just one thing: in UE4 18.1 option r.ScreenPercentageEditor=1 do not affect at all to the image ( even ScreenPercentage value changes nothing - I usually override it to 200).
But quality looks like Editor has this option enabled with some higher value cause the orange object outlines are very thin and objects are very sharp.
And this is version with better HDRI parameters ( contrast ) and lower Global Brightness
Now all hdri-sky light colours are visible on the wall. ( HDRI represents sunset )
Production
HDRI on the Skylight; Skylight set to Static
Static lighting scale of 0.1 15 light bounces (4.18 preview has 15 on the sky lighting)
Lighting Quality of 4
BaseLightmass.ini was modified : NumShadowRaysScale=**16 , **NumPenumbraShadowRaysScale=**64 , **NumHemisphereSamplesScale=32
These settings don’t really have much impact on the style of the final look, as the renderings merely illustrate how nice “true” multi-bounce HDRI Skylighting looks like (Thanks to and ) and why it is so exciting to finally have this in UE4 for Arch-Viz.
In order to get a more stylized look (more like 's mod). as stated in #249 you can disable “Filtering on the Skylight” using **“bUseFilteredCubemapForSkylight=false” **in the Baselightmass.ini, Although the Default set to true is more physically accurate.
The black shadow in corners is due to too much biasing by Lightmass when tracing gather rays. With point and spot lights, only the first bounce uses a gather and is affected by this bug, while the rest of the bounces come from photon mapping which is not affected. With multibounce skylight, all bounces are gathers and are affected by this bug so the artifact is much more noticeable.
This is completely solvable but I just ran out of time for 4.18. It’s high on my priority list.
Higher indirect lighting quality reduces noise and splotchiness in lightmaps, but increases render times significantly. Cranking it up past 4 generally doesn’t do much at all besides increases render times. Even 4 is a bit high if your scene isn’t super clean/empty, such has having textured walls.
Any known workaround? Any tips of settings combinations to avoid for 4.18? If it is on gathering, is it correct to assume the more bounces in NSLB the deeper the effect of the bug?
I haven’t figured out a workaround yet =( Something like VisibilityTangentOffsetSampleRadiusScale or VisibilityNormalOffsetDistance is probably relevant but I didn’t get time to play with it before I had to switch to a higher priority task.
The brighter the 2nd and up bounce of skylight is, the more severe the artifact. Scenes with very bright diffuse (.7 and above) with 90 degree corners have it the worst. Adding a bevel may work around it.
![UE4-17-1-tweaked-[Q=MED, SLLS=0,2 NILB=13, NSLB=na, ILS=0,75].jpg](https://d1ap1mz92jnks1.cloudfront.net/images/transparent.png)
![UE4-18-0P1-cam0+HDRI[Q=MED, SLLS=0,2 NILB=13, NSLB=13, ILS=0,75]-880sec.jpg](https://d3kjluh73b9h9o.cloudfront.net/original/3X/7/7/774a02a5700ec0130e8ac5023838bd585c9f3c26.jpeg)