I have been trying to use GPU lightmass in a level which contains both Nanite and non Nanite meshes. The meshes that are non-Nanite seem to work fine whereas the Nanite meshes are splotchy (this is during the interactive preview but haven’t tried a full bake yet) Also using the Lightmap Density viewmode shows the Nanite meshes as black. So the question is… Is it supposed to work and if so am I doing something wrong ?
1 Like
It’s supposed to just work, and yeah not all the debug views work with Nanite.
1 Like
Honestly I’m surprised you got a result at all during the interactive preview… When I do a GPU Lightmass bake the Nanite meshes are just black until the bake is completed. After that they display fine.
1 Like
Tried a full bake last night and worked fine (probably should have tried that before posting) Also worked out that if you disable nanite from the console, the preview bake works using the fallback meshes. One thing I have noticed though is that Nanite meshes don’t seem to receive any shadowing from the volumetric lightmap.
2 Likes
Did it work for regular SMs? I thought I read that GPULM had limited support for volumetric lightmaps, if any, but I could be wrong. I know that lightmass+nanite are interacting strangely with eachother for the time being, but I think we could see some more work on it come 5.1.
1 Like
It produced some noisy results when it was first implemented but that has since been resolved for a while, since 4.26 I wanna say.
Currently it can’t cast volumetric shadows, but that’s a different issue.
2 Likes
Yep, as soon as I ‘De-Nanitise’ a mesh it gets the indirect shadowing back from the volumetric lightmap. Guess at the moment it is just a case of experimenting and seeing what Nanite can and can’t do. I’m hoping I can find a decent workflow that allows my game to use both Lumen and baked lighting for those with weaker systems…
2 Likes
I know that GPULM currently only uses the proxy meshes, which generally results in low quality/artifacted GI. I wouldn’t be surprised if CPULM alone supports full-quality Nanite in the near-term, as the amount of VRAM needed to hold every Nanite mesh in a complex scene, would be quite large.
Generally speaking, Lumen and baked lighting don’t play well together, including Baked GI and lumen reflections. What the documentation suggests for scalablility to lower-level hardware is to use a combination of DFAO and SSR/SSGI, which generally lets you keep art direction the same for both. Lumen also supports baked AO on static meshes, which brings down the cost as well.
The biggest problem you may run into is dynamic reflections, but SSR + cubemaps + well-planned planar reflections can still work great if you have the time to configure and optimize. DFAO handles specular occlusion as well, so it can help minimize light leaking.
2 Likes
Ah, I see. I think the whole volumetrics system could use an overhaul personally, particularly that RT shadows don’t work with volumetric fog. VSMs are good for many cases but utterly break with soft shadows, and the only ways I’ve found to get volumetrics and RT to work together are extremely hack-y.
1 Like
Thanks for the in depth reply. The main issue I have with DFAO and SSR/SSGI is that you don’t get the same quality of bounced lighting and colour bleeding that you get with lightmass. My game has quite minimalist interiors so the quality of the indirect lighting is paramount. I have found it is possible to swap between baked lighting and lumen in game using console commands but it is a bit buggy and of course the baked lighting often looks quite different to the lumen version.
I am toying with the idea of just having duplicate levels, one with baked lighting and one using lumen although will be a bit more of a pain for multiplayer…
2 Likes
I’m happy to help if I can 
. I agree with you, DFAO +SSR/SSGI dosen’t have a comparable amount of quality to lumen, to the point where the SSGI documentation recommends only using it with other systems like baked lighting. SSGI has some quality settings that help to reduce light leaking and enhance accuracy, but there’s no fundamental solution for the view-dependent problem. And you are entirely correct, even though Lumen looks quite similar to the path tracer on high quality settings, art direction tends to be different between baked and dynamic lighting.
While duplicate levels are an option, what I would recommend stronger would be the data layers system, which lets you swap out large data sets, meshes, and even game logic in-and-out of the same persistent world, as requiring dynamic networking between two separate levels based on hardware type sounds like a nightmare to implement.
If I may ask, what do you mean precisely by ‘minimalist’? If by that you mean a closed, relatively static map, then lightmass should work pretty well, especially with Distance field indirect shadows and SSGI to stop dynamic objects from sticking out. If you simply mean simple in geometric and material sense, and leaning on lighting to do the visual heavy lifting, then your art direction may have some fundamental implications for what path you wish to choose, static or dynamic .
2 Likes
I will definitely have to look in to the Data layers thing, to be honest I hadn’t heard of it till now so am intrigued !
By ‘minimalist’ I mean that I am trying to attain a fairly stark, architectural look for the environments (if that makes sense) rather than the typical sci-fi environments with a lot of busy detailing. Ideally I wanted the environments to look more like architectural renderings than a typical game environment, so in that sense the lighting is very important.
To be honest I could just stick with baked lighting for all of it as it was initially designed for that but Lumen just looks so good, especially the way it reacts with characters (apart from the ghosting) and the ease of use.
1 Like
I see what you’re saying now, yes. Data layers are a new feature, UE5_EA, so you could easily bake lightmaps and keep them on one layer, and the dynamic maps on another. Spawning, game logic, lights and FX and more can live on a third data layer, and should be compatible with both. They’re fast to swap at load or even run time, so it would be well suited to multiplayer.
And on your concerns, ghosting is a problem, but it truly depends on the size of your map and budget. You can tell lumen to flush history faster, but that comes at either the cost of noise or a performance hit. If they’re reasonably small maps, you should be able to crank things relatively far. I understand the aesthetic you’re going for, and I think it’s entirely achievable with lumen. Even though they tell you not to depend on it, lumen emissive lighting is one of my favorite features, as it lets you easily and creatively light a scene however you want.
Just watching some videos on data layers now… Very interesting…
Totally agree about the emissive lighting. I was almost completely relying on it when using baked lighting as it seems to give a much softer light that normal lights and as you pointed out is easy to set up. Works great in Lumen too as long as the light sources are fairly big.
Will have to play around with the lumen refresh times and see how they affect performance.
1 Like
Softer lighting is a big benefit, yes. I think of them like rect lights with arbitrary topology, but you are correct, their biggest problem is the amount of time needed to flush their history. Make sure to check ‘is emissive light source’ in the properties panel, and lumen knows to look for the item and improve tracing and history flushing.
Is there any way to make movable Nanite meshes receive volumetric lightmaps, (like the regular movable meshes do)?
They do that by default
Looks like this is a bug in 5.4… works correctly in 5.3
I would suggest reporting it
That would be great, but when I turn on Nanite on a mesh, it doesn’t receive any lighting from volumetric lightmaps. Tested on 5.4, on many different meshes with different materials. Maybe it’s a 5.4 bug?
It definitely is, I tested in 5.4 and 5.3. Only 5.4 has this issue
I’ve reported the bug, I’ll post updates here when I have any. In the meantime, I’ll try to find some workaround (maybe some setting in the mesh?)
1 Like