"Support for multiple static lighting scenarios" Does this mean we will finally have multi-lightmaps

Trello (UE4 Official Roadmap: Support for multiple static lighting scenarios)
More than half a year ago I implemented my own solution for multiple lightmaps and probes: https://github.com/AlanIWBFT/UnrealEngine/tree/MLDB-4.10.4
Now is UE4 going to implement an official solution? :slight_smile:

Guess we’ll find out soon enough :slight_smile:

Speaking of your implementation, does it work with UE413? :stuck_out_tongue:
Last time I checked it, we were using UE4.9.2 and it was UE4.10.4.
Haven’t thought to check it since we moved from 4.9.2. to 4.11.2 to 4.13.

Currently MLDB is not under active development, because I found serveral problems:

  1. The storage size of multiple lightmaps - We must find out some high-efficiency compression method to store the lightmaps, or we’ll have a huge .umap file. (e. g. A video codec - some crazy idea :p)

  2. The light building time is way too long - This is the critical problem.

So, now I have devoted most of my time to develop the solution for the second problem:
– GPULightmass

The following are some results of GPULightmass. Currently GPULightmass can only bake SkyLight shadow, no light-bounce supported, and it is not integrated with UE4Editor smoothly, so I have to import the baked skylight shadows manually. Some measurements done by me show that the current implementation of GPULightmass is ~800x faster than Lightmass. It is indeed promising, but I probably can not maintain such kind of speed up when the final version of GPULightmass comes out.


PS: The resolution of the lightmaps in the images is 4096 * 4096. The measurements are done on my laptop (i5-4200M, GTX850M, 12GB Memory). Lightmass cannot even bake 4K lightmaps on my laptop, since it eats up too much memory.

That would be cool if they get that in there. There’s a lot of situations where you might want to reuse a level with different lighting so that would avoid having to replicate and maintain multiple copies of the level.

There’s 3 scenarios I could see this being useful.

  1. Day and night versions of scenes when a full day and night cycle isn’t needed
  2. Opening large doors/windows in a scene, completely changing the lighting
  3. Being able to have some baked lighting on procedural generation, it would be great to be able to build lighting on individual rooms that get placed together procedurally.

@Luoshuang : Ahh, I see.
Thanks for the info.

I know JohnJ - works on all the maps for GB - would love lighting to be much faster then it currently is.
Or fully dynamic - one of the two.

What are you intentions with GPULightmass?
Just mucking around? Marketplace plugin?

This is our current problem with our maps are coming in day/night versions.

It has entered master branch, but no blending support:

Blending is impractical because of how it will require both sets of lightmaps to be loaded at the same time increasing the amount of memory it’s using by way too much.

Luoshuang this is a really fantastic work!

It’s possible to switch two or more static mesh and see their static shadow on the world?
For example I work on the Archviz world.
I’d like change chair or sofa or kitchen model and see their shadow baked with static or stationary light.

thanks again

Not for the arch viz crowd who run 32-64gb machines, and will throw a Titan in if necessary.

What’s the status of GPULightmass? Are any builds available?

It would depend on GPU memory, which is very limited. There could be the case that a GPU with 12GB of memory might be able to do that, but you can’t ship a game that depends on that given that most people have a GPU with less than 4GB.

This is excellent news. I wish normal lightmass were sped up a bit… the slowness of light baking made me turn to dynamic lighting.

We have 3 x 3.4ghz, 18 core machines with 96gb of RAM doing lightmass stuff and it still takes an hour for a small apartment at decent settings. Horrific.

Lightmass doesn’t necessarily scale up with the number of processors, each object gets rendered on a separate thread, so if every object has a thread on it, you can’t put more threads on the object to render it faster. What that can also mean is that you can finish all of the threads except for one if the object is large and complex and the other available threads can’t join in and help with the final object. That’s a limitation of Lightmass and hopefully something they can fix, because that’s a very dated limitation.

It is open source (swarm).

Someone go rebuild it for speed, threading and GPU support !




The source for the entire engine is available, so if anyone wants to improve on Lightmass then they’ve had the chance for almost 3 years now.

But would you need all mip maps loaded? Would it be practical to load them like:

Time    Set A           Set B
 |      Mip 0           Not in memory
 |      Mip 1           Mip 10
 |      Mip 2           Mip 11
 |      .
 |      .
 |      .
 |      Mip 9           Mip 1
 V      Not in memory   Mip 0

Just an idea, I’m not sure how GPU memory management even works.

It’s not the mipmaps that’s the issue, the issue is that you would need exactly double the amount of lightmaps to be loaded. Might even be worse depending on how you get the blending result.