Epic's GPUlightmass

[maxbrown]

Epic recently revealed their code for their GPUlightmass in the dev-rendering branch on GitHub. Some people are already playing with it and some (like me) are running into issues.
I think it could be nice if people's experiences with this new plugin could be found in one topic for an easy overview and catching up and to not 'pollute' Luoshuang's lightmass plugin topic.

svv3d was successful in building and using this plugin a short while ago. He wrote:

If you want to test the GPULightmass prototype:
* Download dev-rendering branch from GitHub and build it.
* Enable ray tracing (including switching default RHI to DX12 and check 'ray tracing'. And having a DXR capable graphics card with Win10 version >= 1809).
* Enable virtual texture and virtual texutured lightmaps in project settings (optional, yet without this realtime preview in editor will be unavailable).
* Enable GPULightmass plugin and restart the editor currently no UI has been setup, so just a bunch of console commands r.GPULightmass.xxxx controls parameters and finally, ToggleLightmapPreview to start GPULightmass in editor.
* GPULightmass throttles itself when the level editor viewport is realtime. To make it run at full speed, uncheck 'realtime' in the viewport options.
P.S.:I tested this on my GTX 1070. Everything is working fine.

This week I followed the same steps but the build of UE failed with numerous errors. Suggestions anyone?

[Tjames44]

You can download dev-rendering branch again, I have just downloaded and built it, it´s now working no more errors.

[maxbrown]

Tjames44 Thanks for the update - no more errors and it works. Very curious to see how it goes while testing...

[maxbrown]

Tested with some objects from the RealTimeArchViz scene, generated lightmap coords.Seems like the SkyLight has no effect besides on the color (using a hdri). Directional light has more effect when upping the values for (indirect) intensity to 40 or so. Many splotches everywhere.Using 1024 on both r.GPUlightmass.xxxx. svv3d and Tjames44 any suggestions / links on more info on how to control the quality?

[Luoshuang]

Obviously, this one is super experimental and I would suggest you use it for preview only. To reach acceptable quality for ArchViz, currently this brute force renderer needs at least 16384 samples.

[maxbrown]

Luoshuang, Thanks for the info. Won't use it for actual projects. Any more suggestions for testing at this time besides the sample count? Maybe 'good' light settings for Sky & Directional?

[bioccular]

Replying to keep this thread alive, as people are confusing Epic's GPU Lightmass, with Luoshuang's.

My understanding is that Epic's version is really a preview render. Fast but noisy, unless you give it ridiculous samples.

However, given enough samples and time, it does produce a nicely detailed map. And of course, it's a great way to evaluate light map resolution before sending it off to cpu lightmass.

[maxbrown]

My understanding is that Epic's version is really a preview render.

I would be surprised if that would be the case. With a preview render + low light bounces / high scale you can already do that.
Luoshuang's lightmass is faster but also has better quality. Luoshuang and the Epic team are putting time into something 'new'.
Wouldn't it make sense it would be an even more enhanced version of his original gpu lightmass?

[bioccular]

I would be surprised if that would be the case. With a preview render + low light bounces / high scale you can already do that.
Luoshuang's lightmass is faster but also has better quality. Luoshuang and the Epic team are putting time into something 'new'.
Wouldn't it make sense it would be an even more enhanced version of his original gpu lightmass?

Great! I wasn't aware they were working together. Looking forward to the result.

[maxbrown]

Great! I wasn't aware they were working together. Looking forward to the result.

He works @ Epic now if I'm not mistaken.

[Nocturness]

hi guys just sharing results of my tests on yesterday and yes i love it.

I hope it will be released soon (with quality fixing etc.)

[The_Distiller]

Luoshuang Nice work on the official GPULightmass! Can you please add a cvar to hide the individual (green) progress bars? It's very distracting to have a hundred of them on screen at once and there's still the main one for overall progress.

[BrUnO XaVIeR]

The bars are only visible in slow mode.

[PrizmIzm]

Great work on the new lightmass! I've waited so long for a successor to the existing one.
After playing with it for a while last night there are a few items I'd like to add to my own wish list - obviously Luoshuang and Epic have their own plans for this, but I can only dream.

1. Top of the list is the ability to bake individual static lights to their own lightmaps (or referenced maps) and have those be adjustable after bake. This would be the killer option for any future pre-baked solution for me. This would mean that the pre-baked bounced lightmap of static lights could be faded up or down via blueprint / script. This would allow day and night scenes to be baked for each map (UE level) and then fade them up as the sun rises. Failing that, just having a more simple 'channel' system that allowed you to assign sets of lights to a bake channel, then that channel could be faded up and down at runtime.
2. Proximity aware baking - this probably has a better name, but it would mean that, if you have a large level that you've already baked most of the light for, and you want to adjust a small light somewhere within the level, then lightmass would only rebake the objects that are effected by the change - rather than the entire level over again. Failing that it would great to have the ability to lock lightmaps for objects once baked, so they're ignored in future bakes. Huge time saver either way.
3. Ability to draw volumetric light density boxes (also exposed in construction blueprints) - the fully automatic system at the moment is useless at optimizing itself for complex meshes (which makes matching the light conditions of static and movable meshes very difficult). If we could draw volumes that dictate volumetric probe density around any object we'd like then that would solve those cases. It's great to see that new GPULightmass works with the current volumetric light probes, but the current light probe system is pretty useless and doesn't allow much granular control (plus it can only populate cubic areas, so it produces loads of wasted light data in the air above geometry!). Unigine and Unity have versions of this functionality, please consider adding this if you can.
4. Multi-GPU support - big must, but I expect it is already in the works. Multi GPU on local machine and multi GPU networked machines too. Crazy not to have this.

Big asks I know, but what a difference they would make. I'd really love any news on these.
Here's some other things I noticed whilst playing around - which I assume the devs already know, but I'll put them down anyway.

1. Light Intensity for skylights and Indirect light intensity for all lights do not seem to have any effect right now, lights all seem to be stuck on their default intensities.
2. Directional Light Source Angle not working - would love to see this working, at the moment only pin-sharp sunlight supported, no ability to mimic overcast conditions.
3. Toggling 'Lower Hemisphere is solid color' seems to have a dramatic effect on the accuracy of skylights, they go from blinding in all directions when on, to accurate when toggled off.

Anyway, I'm done being annoying and entitled. Really great to see progress being made on this and can't wait to see where it goes!

[Luoshuang]

Great work on the new lightmass! I've waited so long for a successor to the existing one.
After playing with it for a while last night there are a few items I'd like to add to my own wish list - obviously Luoshuang and Epic have their own plans for this, but I can only dream.

1. Top of the list is the ability to bake individual static lights to their own lightmaps (or referenced maps) and have those be adjustable after bake. This would be the killer option for any future pre-baked solution for me. This would mean that the pre-baked bounced lightmap of static lights could be faded up or down via blueprint / script. This would allow day and night scenes to be baked for each map (UE level) and then fade them up as the sun rises. Failing that, just having a more simple 'channel' system that allowed you to assign sets of lights to a bake channel, then that channel could be faded up and down at runtime.
2. Proximity aware baking - this probably has a better name, but it would mean that, if you have a large level that you've already baked most of the light for, and you want to adjust a small light somewhere within the level, then lightmass would only rebake the objects that are effected by the change - rather than the entire level over again. Failing that it would great to have the ability to lock lightmaps for objects once baked, so they're ignored in future bakes. Huge time saver either way.
3. Ability to draw volumetric light density boxes (also exposed in construction blueprints) - the fully automatic system at the moment is useless at optimizing itself for complex meshes (which makes matching the light conditions of static and movable meshes very difficult). If we could draw volumes that dictate volumetric probe density around any object we'd like then that would solve those cases. It's great to see that new GPULightmass works with the current volumetric light probes, but the current light probe system is pretty useless and doesn't allow much granular control (plus it can only populate cubic areas, so it produces loads of wasted light data in the air above geometry!). Unigine and Unity have versions of this functionality, please consider adding this if you can.
4. Multi-GPU support - big must, but I expect it is already in the works. Multi GPU on local machine and multi GPU networked machines too. Crazy not to have this.

Big asks I know, but what a difference they would make. I'd really love any news on these.
Here's some other things I noticed whilst playing around - which I assume the devs already know, but I'll put them down anyway.

1. Light Intensity for skylights and Indirect light intensity for all lights do not seem to have any effect right now, lights all seem to be stuck on their default intensities.
2. Directional Light Source Angle not working - would love to see this working, at the moment only pin-sharp sunlight supported, no ability to mimic overcast conditions.
3. Toggling 'Lower Hemisphere is solid color' seems to have a dramatic effect on the accuracy of skylights, they go from blinding in all directions when on, to accurate when toggled off.

Anyway, I'm done being annoying and entitled. Really great to see progress being made on this and can't wait to see where it goes!

1. Does the current lighting scenarios system work for you? What's its problems?
2. This will probably be implemented in the form of 'bake only selected objects'
3. This is unlikely to happen in near future. When we were implementing VLM streaming for 4.24 we thought about that possibility however we didn't figure out a way without incuring significantly higher per-pixel cost compared to current system (especially when you combine it with volumetric fog). We may think about that again in the future.
4. This is on the list.

For the bugs, 1 and 2 are known and will be fixed in the following commits. 3 is new to me - was the editor compiling shaders when you ran GPULightmass? Does forcing a skylight recapture fixes it when the lower hemisphere option is on?