@maxbrown Try using First Bounce Ray Guiding with a fairly high number of trial samples
Edit: Setting trial samples to 25% of GI samples seems to give good results, see my reply below
@Arkiras Thanks for the suggestions. Its looking better now although I’m getting crashes if I make the values too high (gtx1080 - maybe too old for this new tech). Will test more - also on a 20-series card.
I suspect trial samples uses the first X number of GI samples as guidance for future GI samples. Meaning its limited by the amount of GI samples you have, so if you set GI samples to 512 and trial samples to 512, it essentially does nothing. I’m guessing the trial samples may need to be kept in GPU memory also so perhaps that is causing the crash for you.
My testing seems to bear out this conclusion perfectly:
Following that logic, I gather there is a probably “sweet spot” for trial sample count, where by continuing to increase the value just gives you a worse result because there aren’t enough regular GI samples to take advantage of all the trial samples.
Not sure where the tipping point is (intuitively I want to say 50% as that seems to make sense), but I think it is a good idea to use the defaults as a basis for determining what to set. By default the Trial Samples are 25% of the GI samples (128 trial samples / 512 GI samples) and I find this works pretty well. So if you were doing 1024 GI samples, you’d use 256 trial samples. In my case for the comparison in my previous post, I used 8192 GI samples and 2048 trial samples…
First bounce also seems to have some bugs, I sometimes I get blocky artifacts and broken results between tiles. Not sure why.
Hello! I’m getting this errors after the light build. You can see there are pixels on the walls. Any idea on how to fix that?
There are my settings:
I already tried some stuff and wanted to let you know: (lately used preview 4)
Had some issues with skylight and realized that it’s only calculated when I change some skylight settings while baking (in preview mode; f.ex. lighting intensity +0.1). This even works when I don’t activate virtual textures at all.
Which brings me to my second experience: Previewing is nice to have but I can only make sure that I got good FPS and no artifacts when I disabling virtual textures (I got a big scene). Maybe you know if there’s another solution with better virtual texture settings? (I guess this might cause youre pixel-errors @xaviprz)
Still I have lots of crashes and errors I don’t know a lot about, but I thought it might be useful to kind of share these things with you!
Im using RTX 2080 TI.
Hey guys, just DL 4,26 to try out the gpu lightmass. Is there a main thread where it shows how to use it? im confused in how to change the setting to get a clean image. All it shows is the menu with the green bar with very little settings to change. What setting on there actually clean the image?
@syrom good question. Struggling with the same problem. Until some documentation is released by Epic its a bit guessing what settings actually are beneficial to the render quality.
Bit of a long shot asking during the preview. But I just setup 4.26 preview 6 and GPU Lightmass baking is very dark with static spot lights. I need to crank up the intensity to 64 cd to get some light in my scene with them.
I’ve tried to follow the various videos here to see the settings people are using but no luck.
Basically isn’t anything we can do except wait for fixes for most of these issues
Is 4.26 official GPU Lightmass more or so production ready? What’s missing (preview 7) compare to CPU Lightmass / non-official GPU Lightmass ?
I can’t open my projects in preview 7 without crashing so I will answer based on preview 6:
- Denoiser creates seams between meshes
- Denoiser creates colored artifacts when lightmap compression is enabled (I think this is due to denoising happening after compression, but that’s just a guess)
- Volumetric lightmap doesn’t build properly and is very noisy
- First bounce ray guiding sometimes creates blocky artifacts
- Stationary Skylights are unsupported
- Area shadows for stationary directional light produces different results than CPU lightmass
- Doesn’t seem to sample light color properly from the skyatmosphere system resulting in much whiter color temperature from CPU lightmass
- Intensity of static lights behaves strangely depending on the light settings, not consistent at all with stationary lights
- Most lightmass features are unsupported (Indirect lighting intensity, diffuse boost, AO, ao material mask, etc.)
Probably lots more I am forgetting.
If you’re fine with a bit of noise and you have a very static scene then it’s probably usable. For what does work, the results are excellent and if you’re making an archviz scene with lightmap compression off you can get really gorgeous results. Unfortunately because of the issues with the denoiser I find I have to turn it off and max out the sample count.
For dynamic scenes, I would say it is not usable at all. Mainly this is because you can’t generate a proper volumetric lightmap, but also because of the generally sparse support for stationary light features. For example, the inability to adjust the indirect lighting intensity means you can’t use a stationary light in a room where you can turn a light on and off.
Thank you for compiling such an awesome list about the bugs I have created! :o
Anything regarding the denoiser is something we don’t have much control about 
. We’re relying on Intel’s Open Image Denoiser which is basically an AI blackbox. For seams between meshes it is a general problem with denoising and I don’t see a clear solution in the near future. For colored artifacts, if they appear more on the borders of a lightmap I may have a weird idea to improve that. If not we then don’t have much can do about it
There is a bug with VLM now that if you change only lights and not objects it will not invalidate properly and you get residues from the last bake.
Denoising doesn’t work with VLM because it is 3D - I can try adding a hacky parameter like ‘VLM GI sample multiplier’ to boost its quality
That’s the nature of FBRG - it tries to share info in a small block so that if any of the texels in the block finds some important incoming light, all of them can find it. If the number of FBRG samples are insufficient because the lighting condition is hard and none of the texels in the block finds anything, the block artifact appears.
Coming in the following releases, but may take a little bit longer than expected. Like, we have fixed a bunch of path tracer correctness issues in UE5.0
We don’t support SkyAtmosphere directly. It is supported through skylight captures. So if skylight doesn’t capture properly or it has some unexpected parameters things will go wrong
For ppl have been using my old Luoshuang’s GPULightmass:
If you want to reach quality parity, you need N^2 samples, like if you have 64 PrimaryGISamples you then need 64^2 = 4096 GI samples here. And also turning on IC and FBRG. Basically the old one = the new one with N^2 samples + IC + FBRG enabled, and 4x slower :o. Reason why I still choose to make it slow is that
- Better VRAM consumption. I have added instancing support and chosen a slower algorithm in general for diffuse GI (path tracing vs. radiosity which is pretty much born for the problem but takes a lot of memory). It is possible to bake a forst now.
- Better material evaluation. Instead of using a simplified texture to represent the entire material, it actually evaluates the material shader on GPU when baking, so that material nodes like AbsoluteWorldPosition and PerInstanceRandom and painted vertex colors can work. Also by having this full material representation it is actually possible to render caustics into lightmaps now - it is just disabled, because obviously nobody will want to use path tracing to render caustics as it is hella slow with them. However for curious people they can try to change FORCE_ALL_MATERIALS_DIFFUSE to 0 at the beginning of LightmapPathTracing.usf, setting SIMPLIFIED_MATERIAL_SHADER to 0 in LightmapRayTracing.cpp and see what happens. Note that IC and FBRG should be disabled in this case.
That being said, I’m still working on perf optimizations and hopefully we can get something faster.
Thank you for the response @Luoshuang !
Ahhh that’s unfortunate I suppose I’ll treat it as a setting for preview bakes then
Is there a best practice for determining how many Trial Samples should be used with FBRG? I wasn’t really sure so I’ve been just been basing it on what the default was set to (Trial Samples = GI Samples * 0.25).
Also am I correct in assuming Trial Samples is shared with GI samples? So if you set Trial Samples and GI Samples both to the same value, then every sample will be a trial sample?
Wish I could manage to get a project launched to test but from what I was experiencing it looked like a problem with the directional light not the skylight. It seemed like the SkyAtmosphere was setting the color of the directional light (so that it was more orange when closer to the horizon) but this didn’t seem to be accounted for by GPU LM. I may be remembering this wrong though, I can’t test it at the moment
Very much looking forward to it 
Yes, 25% is the recommended value. The basic idea about first bounce ray guiding is that it traces a few samples (‘trial samples’) to get a rough general idea about how the lighting in your scene is and the samples are then thrown away because they may be low quality. A final pass is then executed using the info gathered from these trial samples. So, yes if you set them the same value no GI sample will be taken at all.
Understood, thank you for the clarification
Has anyone tried building lighting scenarios using GPU Lightmass? How about streaming levels + lighting scenarios ?
gpu lightmass is kind of pointless now if the intensities of point static lights dont match the light probes or the lighting of what they would look like stationary… Not to mention the 128 light limit … well kinda makes it pointless for lighting a scene unless your lighting your scene with all emissive shaders.
I think fixes for that were committed to 4.26 repo earlier today.
There is a macro that defines # of lights, but maybe @Luoshuang can step in and guide us through the process of how to increase number of lights ?
EDIT: A rumor has it that the macro is called RAY_TRACING_LIGHT_COUNT_MAXIMUM (note: changing this value will force a recompilation on the entire engine + all shaders; I haven’t tried it, so if you do - please tell us here if it worked 
)
yea im not going to mess around with all that… im just an artist with an rtx 3090 as my main comp… and 2 rtx 2080tis on my other machines… would be cool to be able to use them in swarm configuration… but id be content with just it working great on my rtx 3090… without the limit of lights…
You can’t have distributed lighting build with GPUs afaik (or maybe you can, but it’s not trivial task perhaps).
I was “just an artist” too. Had to learn some things to get ahead instead of waiting for Epic to provide what I needed in the launcher build