Lightmass: multi-bounced sky lighting

Hi guys! First of all, I want to congratulate the Epic Games Team, and rafareis123 for their excellent work.

I found a very simple solution to solve the problem of the black corners of the engine 4.18.

Surely this solution will have happened to more people.

In the following example, you can see the same geometry resolved in two different ways. In one I do not apply chamfer in the corners and in the other I apply a 5mm chamfer in all the corners and projections of the interior space.

The render parameters:

  • Quality: Production
  • Portals: NO
  • Changes in BaseLightmap.ini: NO
    -** World Settings: **
  • Static Lighting Level Scale = 0.15
  • Num Indirect Lighting Bounces = 7
  • Num Sky Lighting Bounces = 7
  • Quality Lighting: 5

To illuminate I used a static Light Source and a static SkyLight with an HDRI 05-28_Day_D.

Nothing special.

Greetings from Seville, Spain.
architect.

So is the building one continuous piece of geometry? Are both convex and concave corners beveled?

Hi ZacD!

For this example, I’ve searched for the quick way to do it.

First the 3d modeling I did in Autocad, since architects usually work a lot with this program or Revit.

All architectural geometry is united, that is, it is a single solid.

In 3ds Max, I separate all the outer faces as a piece, and then apply the chamfer to all the remaining geometry and they will be concave or convex.

Then for example, I select all the ceilings along with their chamfers and I leave it with SM_Techos, I do the same process with the floors. The walls are left for the end as it is faster to select and be able to separate them together with their chamfers. In the latter case, I’m building lots of walls so that the resolution of lightmaps are similar in all cases.

The truth is that it takes longer to tell than to do it.

I have used for all Lightmaps pieces with 1024x1024 resolution without compression.

By the way, I do not know if anyone has happened to it, but if I use 2048x2048 resolutions without compression, there are always some errors when loading those maps, so I always try to create pieces for 1024x1024 maps.
Has this problem ever occurred to you?

A greeting.

architect.

Thanks for the detailed information @estudiobarrera

Is it possible to provide a Google Drive or Dropbox link for the static meshes you used for that example?

We would really need a popular Github like open source free for game project, by witch I mean free for any size of assets and with gigabytes of Large File Storage and unlimited bandwidth…

Edit: Gitlab.com does offer a somehow this for open and close source projects up to 10GB

i tried many times in past to resolve with chamfer
it depends about connect edges
so u need to improve light map too

basically if u use a big light map resolution and your walls will be red you have no black corners couse black corners are jusst a kind of shadows

another tip is to create a “small corner” with high light map to apply over meshes

Hello again!

Here is a link to download the example in UE 4.18: Download example in UE 4.18

Regards!

architect.

Wrong link.

Hi estudiobarrera,

Your link is not working. Folder does not exist. Could you please reupload it again or share it in another way.

Thanks in advance!

Ok sorry!

Already solved.

Here is a link to download the example in UE 4.18: Download example in UE 4.18

architect.

@estudiobarrera Thank you for the link and for the solution.

But on other hand this is really bad workaround if there are already 3d modeled apartments/interiors with applied lightmaps. Meaning everything that we made before is not usable for chamfering since time = money and I really dont think that redoing everything just to chamfer concave/convex corners is a solution to the problem for arch-viz commercial production.

Why no one is using the adjusted values of VisibilityTangentOffsetSampleRadiusScale and VisibilityNormalOffsetSampleRadiusScale as suggested? The adjusted values from @ are working really well, I think (I havent the time to look more deeply around). So I am just really confused on why the chamfer workaround is better than just adjusting the variables?

Hi @NasteX !

I commented that I did a test with 's solution and in my case it did not work. I think I did something wrong.

Logically, the solution I propose is not final and much less applicable to a previous project.
Simply, from now on, I will apply chamfers in the 3d modeling of my future projects.

architect.

Tested your settings on medium quality (production on the way) I think it’s really promising! :slight_smile: The scene is lit by a single HDRI…
Thank you!!

Hello again!

I have done a test with the model I added, modifying BaseLightmass.ini as indicated by @

On this occasion I have obtained interesting results.

The renders parameters are the same as I mentioned in #307

I attach images.

architect.

Coming in 4.19:

Change 3716271 by

Lightmass correctness fixes

  • After these changes, point, spot, directional and sky lights closely match reference renderer Mitsuba after light unit conversions

  • Photon density trimming intended for direct photons was affecting indirect photons as well. This caused high noise for point / spot lights with a large attenuation radius. Indirect photon density even for small lights is 5x with this change, which improves 2nd bounce quality.

  • Removed legacy fudge factor on point / spot light photon energy

  • Spotlights no longer emit based on indirect photon paths. Fixes excessive photon energy from spot lights as they were emitting outside of the cone.

  • Fixed photons computing one more bounce than requested.

  • Added an option to use the Radiosity solver for all multibounce, replacing photons. Useful as a reference but generally too much noise indoors.

  • Fixed visualization of photons without final gather

I imagine that this fixes (among other issues) the bug mentioned here:
https://forums.unrealengine.com/development-discussion/rendering/112665-lightmass-incorrect-indirect-path-driven-photon-emission-for-spot-lights?139844-Lightmass-incorrect-indirect-path-driven-photon-emission-for-spot-lights=

I’m not sure if this fixes the “incorrect dark corners with multi-bounced skylight” problem, would need to chime in on that.

BTW, are you guys planing to upgrade Intel Embree version used in UE4? The current one is quite dated, and new versions have some nice performance and memory usage optimisations.

New Features in Embree 2.17.1

  • Improved performance of occlusion ray packets by up to 50%.
  • Fixed detection of Clang for CMake 3 under MacOSX
  • Fixed AVX code compilation issue with GCC 7 compiler caused by explicit use of vzeroupper intrinsics.
  • Fixed an issue where Clang address sanitizer reported an error in the internal tasking system.
  • Added fix to compile on 32 bit Linux distribution.
  • Fixed some wrong relative include paths in Embree.
  • Improved performance of robust single ray mode by 5%.
  • Added EMBREE_INSTALL_DEPENDENCIES option (default OFF) to enable installing of Embree dependencies.
  • Fixed performance regression for occlusion ray streams.
  • Reduced temporary memory requirements of BVH builder for curves and line segments.
  • Fixed performance regression for user geometries and packet ray tracing.
  • Fixed bug where wrong closest hit was reported for very curvy hair segment.

Dear EPIC, that should be must have update for upcoming versions. Perhaps EPIC developers already have seen it but lets help to notify them just in case.

Sadly no. It is on my list! So much to do, so little time. Not sure if I will get to it by 4.19.

I tested an upgrade to latest Embree (2.7 -> 2.17). Performance was nearly the same, so I reverted the upgrade. It’s not worth the careful regression testing we would have to do, for the same build times. Many of the recent Embree performance improvements only affect special types of rays which are not in heavy use by Lightmass. If our Embree usage changes, or a new Embree version comes out with improved performance, we will re-evaluate the upgrade.