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?
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?
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.
@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?
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.
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?
@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.
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.
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.
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.
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.
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.
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.
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.
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!
Does the current lighting scenarios system work for you? What’s its problems?
This will probably be implemented in the form of ‘bake only selected objects’
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.
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?
So I am the author of Luoshuang’s GPULightmass, and I work at Epic now (for ppl don’t know) and I’m also the author of the new DXR GPULightmass.
The new one currently hasn’t got all my old algorithms from Luoshuang’s GPULightmass, and it does more work, so it is much slower.
The new one is able to evaluate material shaders during the bake so material expressions like AbsoluteWorldPosition, per-object painted vertex colors can work. It also switched from radiosity framework to path tracing for massively improved video memory consumption, and in-editor realtime preview. This together with the support of instancing, you should be able to bake large scenes which previously will crash Luoshuang’s GPULightmass. Also path tracing is slightly more accurate than radiosity so you should see fewer artifacts than before. (‘Slightly’ because radiosity’s accuracy increases along with lightmap resolution, so for ppl using super high lightmap res it is almost as accurate as path tracing, and that’s why my Luoshuang’s GPULightmass can beat a lot of path tracing based renderers in terms of quality).
However with the increased workload from evaluating true material shaders + incoherent rays from path tracing, while it is hardware accelerated, it may not reach the speed level of Luoshuang’s GPULightmass even after I’ve migrated all algorithms over (radiosity caching as secondary GI engine, spatial adaptive sampling - a limited form of path guiding). It will be much faster than its current state though.
Thanks for the response, and good to known about the progress, I’m sure other people will want to know about these things. I’ll try and answer the best I can.
With CPU Lightmass you can bake a skylight in stationary mode and then adjust it’s own intensity + Indirect Lighting Intensity within a post process volume - that gives the effect of fading in / out a baked daylight scene. There are several limitations to doing this 1. When you fade down ‘Indirect Lighting Intensity’ in the postprocess volume, it fades out the influence of all baked lighting and volumetric light probes in the level - so if you’ve baked any other lights, they’re gone also. 2. This method can only contain one lightbake and not several different ones; so if you wanted to bake a day scene, an evening scene, and a night scene, and fade between them then you’re stuck. 3. CPU Lightmass is hugely inefficient and slow. I personally want to bake lighting for an open world town (indoors and outdoors), but the quickest I can get it down to (without loosing too much quality) is about 3 minutes per building! 4. CPU LM doesn’t allow me to just rebake the area I’m working on, so the idea of re-baking a whole town every time I change a single light is unthinkable.
This is VERY encouraging - such a simple fix would save thousands of people, thousands of hours!
This is a shame - the most simple system I could think that would cure a lot of woes would use the same probes that are in the editor right now, but just allow the drawing of a simple volume and for there to be a vertical and horizontal density slider which would populate the volume with a grid of probes. Another massive addition would be the ability to darken / lighten those probes after bake - this would allow artists to be able to exclude volumetric fog from indoor areas (another huge feature for a relatively simple change).
Awesome! I figured that would be a priority. My GPUs are ready.
Bugs
Editor was not compiling and I was using an SLS cubemap (not a captured scene) so there’s no way for me to recapture.
I hope all this helps. I can see real potential here once all your algos are in and the efficiency is up. I was a big fan of your independent GPULM, I’ve used it a lot.
