Volumetric Lightmap Density Volume Not Working Properly

Hi all, I’ve been struggling to get this working properly. I have this ArchViz project and in this image the detail cell size is set to 2, the maximum brick memory is set to 50 and spherical smoothing is 0.2. There are areas where the spheres are TOO FAR from each other and other places they’re really close yet both situations don’t work properly. I’ve tried higher values on memory, lower cell size and smoothing 0.02 but every time I try again the result is the same ugly blurred dots. How to make it work properly? I followed some tutorials, used the tutorials values and still have this problems. x.x
Any help?

  1. This is waaaay too dense of a volumetric lightmap
  2. Your problem seems to primarily be an issue of noise, not density.
1 Like

Detail Cell Size 2 is incredibly low, especially at 50 memory. I’m thinking that the interpolation of lighting and shadowing among spheres is so tightly compacted that it’s bringing in unwanted lighting near surfaces and also unwanted shadowing data on those wall / door surfaces. You may also be running out available memory to get the entirety of the data resolved. That or the lightmap resolution of the meshes is too low. What are the light settings for the scene, that area in question specifically in addition to directional and skylight?

Remember, memory block data is how much memory per 8-point voxel in the volume, which includes all 8 spheres per block / voxel. The volumetric lightmap also places more high-density samples nearer to surfaces, in particular surfaces with varying detail (even on doors / walls), so it could actually be reducing the capacity of the lighting to accurately sample lighting and shadowing for plain white walls / doors. And there’s a set amount of total memory to be utilized for the whole volumetric lightmap volume, in which samples at the perimeter of the high-density / detail areas get culled for efficiency and more memory availability to the rest of it.

Are your light build settings at High or Production? Should be. Minimum lightmap resolution of those meshes should be 256 or 512, with optimal probably at 2048. Don’t do 4K or it may break down the volumetric lightmap’s ability to fully solve. Set the Min LM Size to the lowest possible to use, so 256, and the actual LM Size / Resolution to the same or higher but never lower than the Min property (this is all in mesh editor > Build > LOD0 settings).

1 Like

Thanks for the answers! I tried reducing the noise, it just got worse. Used brick memory 512 and also deleted the volumetric density volume, the result went way better but still with some issues like before but this time less intense. Still annoying though. I’m using 512 lightmap resolution for the doors, the settings are all set to production and there’s only an HDRI static skylight casting light to the entire scene.

It doesn’t make sense to me the scene looking better without the volumes, wasn’t it supposed to be responsible to make these spheres lighting info be more accurate?
Thank you so much again for the answers, it did helped me a lot!
In this image I used cell size 4, memory 512 and smoothing 0.1.
I’m trying other settings to see if I can find the best one to use. Thanks again

What version of the engine are you using and how are you building the lightmap? Epic’s GPU Lightmass plugin? Cpu Lightmass?

1 Like

I’m using 4.27, rendering using Luoshuang’s gpu lightmass

Try Epic’s GPU lightmass. As I recall, 4.27’s GPU Lightmass has a setting in it for volumetric lightmap quality

1 Like

I reinstalled unreal, the gpu lightmass button was undersaturated and didn’t allow me to click. The plugin was set, raytracings and virtual textures were enabled on project settings… It’s getting hard.
I tried again on the settings and looks like you were right, reduced the cells size and noise, got a better result. Still not my target yet the best result I got so far. (the build was set to low values that’s why the walls look ■■■■)

Increase detail cell size instead of keeping it so low (less than 10 is too low I think, particularly for the scene which is filled with bright textures on the walls/doors). Try something like 40 or 60, maximum of 100. I would turn off virtual texturing if I were you. It may be interrupting your ability to get proper results for the lighting on textures and the noise appears to be occurring mostly around the corners / edge parts of the geometry. The door frame inner areas are noisy / splotchy, the back corner of the shelf or dresser object at right is super noisy. The problem is the indirect lighting is not getting calculated completely / correctly. Check every mesh in the scene to see if any are set to stationary or movable. It could be causing anomalous lighting and shadows. Set all meshes to static except for the ones that are going to change color, set to Stationary.

It’s also noticeable that the plant, dishes, chairs, table / counter are not getting noisy results. Does the scene contain any ray tracing?

1 Like

Looks exactly like the same type of artifact I was getting on light bakes, so I doubt LPV is the only source of the error.

I can tell you what it shouldn’t be:
Spot light/point light overlap
Dynamic/directional (staric) light penetration.
Single/manifold mesh.
Light map UV
Light map res.

You may want to have a look at all of those anyway, but none of them solved the bake issue for me.

The actual lightmap bake is just baked in with that weird light ondulation artifact, and lpv is off in that specific project.

1 Like

(Epic’s) GPU Lightmass had an issue up until 4.27 where the volumetric lightmap would produce noisy results. It was improved in 4.27 with the volumetric lightmap quality setting. I have never used Luoshuang’s GPU lightmass plugin but I wouldn’t be at all surprised if it suffers from the same issue, as it hasn’t been updated in ages and Luoshuang now works for Epic on the official GPU lightmass plugin.

Your best options are to either use the official GPU lightmass plugin (requires a raytracing capable gpu) or try CPU lightmass.


Well, thanks for your replies, I’m still having same problem. I had better result using 40 as cell size, yet some doors gets a terrible black “contour” . I tried native GPU rendering and the result is the same but took longer to build lol
Anyhow I got a brand new problem x.x’
Despite I’m not really happy with the doors, I decided to keep going with the project and imported the other levels into the scene (environment houses and backyard), which I build the light already on them. The problem is when I import these levels, the doors get extremally bright as if they were emissive objects. Now why is this happening? Are these other levels bringing in the light info used on them together into the main level?

It may be the light from the other levels is adding to the skylight capture result. Unless you’re using a specified cubemap for the skylight, which would be not capturing color / light from the scene in the level and instead a different cubemap, then it’s going to use all the lighting data in the scene to re-project light into the scene.

Another possibility is the materials are set so they’re causing too bright of a result. It’s hard to say without more information. Can you post a picture or two of the assets from the other levels you imported, and a picture of the super bright doors?

This is how it is looking now ↓

This is the lvl I’m importing, the backyard ↓

And this is how it looks like when I import the lvl backyard ↓

I’m using only skylight as static and directional light on the garden as movable. I imported the skylight into each lvl, built the light and deleted it right away with the lightmass importance Volume, then I imported into the main lvl which is the one with the house.

Why is the level backyard in the street? That’d probably be screwing with lighting result using static skylight. I noticed the indoor room got much darker, except for the doors. It’s like they became excluded from the bake. Did the over brightened result happen after bringing the other level assets, but before baking? Dynamic directional probably wouldn’t cause that by itself, or in combo with the static skylight, but it could’ve saturated the outdoor areas with a pure white and transferred it to the doors through the skylight cubemap. I’m not sure if baking lighting for assets in one level, then importing them to another level is feasible in the scene you’ve created…at least when performed simply and not considering / knowing how. Try moving the doors a really small amount in a direction, such as by adding .001 to the X value of location. What ambient occlusion settings do you have?

If the end purpose of the project here is ArchViz you need to re-think re-factor your level build.

Doors as movable objects are sure cool, but if the idea is it to get a clean render, move them where they have to be, and bake. Snap your snaps, shoot the footage, then open the doors and bake again.

It’s really the only way to get decent and even light on all objects.

If on the other hand you are making something playable. Then dump baked lights completely and set everything up for runtime.

The engine doesn’t do that well at mixing the 2 - though it is possible to get acceptable results too. It depends a lot on setup, mesh control, etc.
99.9% of the time, the issues you get are light bake related. And about 50% of the time, you can manually fake a decent light on moving objects by injecting a custom texture as the AO into the movable object…

Guys, I kinda solved the problem.
Thank you all so much for the replies, you did help me a lot!
The project is an interactive project, that’s why the doors drama. I figured out the thing with the lighting, looks like when you import a level into your current one, it brings up the light information, itherefore on my map where there’s only the garden, it brought the light info from the location the house is in the main map, so it brightens up the scene when imported. Does it make any sense? Not sure if I’m explaining well my feedback from it.
Anyway, I packaged the way it was just to see, and surprisingly it ignored the bright that appeared after importing other levels. Apparently it’s a bug.
That’s it, thank you so much for the help, really appreciated.

thanks for updating about it…
did you try baking light again after bringing in the assets from the other level(s)? and did it worsen it or improve it in any way?

I didn’t, I separated the backyard into another level because it was running out of memory when baking. It got just fine, I baked the light again a couple more times on the main lvl tweaking the cell size until I get happy enough with it, then I imported the other lvls again, despite the weird lighting on movable objects, when packaging it considers only the light built on that lvl and runs correctly.