today I installed 4.18.0 to test the new lighting features. I´m running into various problems with Volumetric Lightmap samples. First of all if you look at the first image I attached. The sphere and cube on the left are dynamic. You´ll notice there are regions where no volume samples are placed at all. In these regions dynamic objects become partial white (outside environment color). I tried various settings for “cell size” and “maximum brick memory limit” without success. Also “Lightmass character indirect detail volume” seems to have no effect on the new method. The second problem occurs in regions where samples actually are placed close to the ceiling or walls. But those samples again receive the outside environment color. See the area on the ceiling I markes red in the first image. In these regions objects will get a wrong lighting, too. It seems that I have to dramatically decrease the cell size to get a half decent lighting for dynamic objects(disregarding problem one). So low that it doesn´t make any sense in terms of performance.
So I switched back to the old method “sparse volume lightin samples”. Of course the shading is not as good as the new one. But even with a much lower resolution I get correct light on samples near the cailing and walls. But this method doesn´t seem to work at all. Look at screenshot 2 I attached. Both dynamic object just stay white and the samples seem to have no effect.
Volumetric Lightmaps produce less leaking than the previous method (as your comparison shows), but leaking does still occur. Leaking can only be solved completely with techniques that do manual interpolation, which are very slow to render.
That said, the failure to create the highest density samples in that one area affecting the sphere is definitely a bug. I would also not expect any of the samples at the ceiling but inside the room to be picking up the directional light. Could you upload that scene for me so I can investigate?
I’m also experiencing the light bleeding in some samples near the walls. I’m avoiding that with thicker walls when necessary.
About the lack of high density samples near some surfaces, I don’t know how the engine chooses where it should places them. I believe it should be near all the static surfaces, but it seems to fail in some areas like I show bellow.
No high density samples near that wall on the left…
… but the other wall in the same room gets the samples just fine:
Both walls have the same thickness and same distance from the nearest lightmass importance volume boundary.
You can find the scene, here. http://sorceress.netfrag.org/VLM/Test4181.zip
It contains two levels. One build with VLM and one with spares VLM. Also notice that sparse VLM has no effect on the dynamic objects anymore unlike in 4.17. I attached a screenshot from the same geometry loaded and build in 4.17. Here the sphere on the left becomes a lightness that you would expect.
Regarding the new method. In general it´s really fantastic in areas it works. See my second attached screenshot. The torus Knot looks like it´s rendered static with the red bleeding from the cube !
Good Job ! This is a kickass features if the bleeding problems can be overcome.
I though about how the light bleeding could be resolved. As rabellogp wrote the bleeding behaviour can be overcome by making thicker walls. But this is sometimes not possible in archiviz, obviously. The problem as far as I understand is shown on screenshot 3. (not adaptive in this case just for demonstration purpose). The samples are placed on a global grid and a wall can be between two samples wich causes objects in this areas become to bright. The only solution we currenty have is. Making the walls thicker or making the grid so dense that it´s granted a sample is directly in the wall. Wich probabely also wouldn´t be 100% correct.
Two methods I could imagine. ( Btw. I´m not a developer so I don´t know if this is technically possible).
A volume that in the first step removes (or ignores) all samples from the global grid and replaced them with it´s own samples in it´s own coordinate system. This volume would not interpolate with samples from outside .See screenshot 4. An advantage of this method also would be that you can define a resolution in certain areas by yourself. I mean it could also be adaptive. It would make sure that the lighting is critical regions is always correct.
Also a volume. But other than method 1 it wouldn´t replace samples. Samples from the global grid inside the volume would interpolate with each other but not with samples outside the volume.
See screenshot 5. This would also make sure the lighting is correct. But other than the first method you could not adjust a resolution.
As I said. I´m not sure if this is possible but it would be great addition.
The unexpected light leaking near the ceiling (where samples inside the room are lit by directional light, and lack of detail samples) are caused by a bug in the brick trimming due to MinBrickError. This will be fixed in 4.19 but in the meantime you can go into BaseLightmass.ini and set MinBrickError to 0 to workaround it.
After that, the remaining leaking is caused by DetailCellSize being too low. To completely prevent leaking with Volumetric Lightmaps, you need to have 2 samples inside each wall. Your walls are 3cm thick, so something like 2cm for DetailCellSize works to remove all leaking. That’s a lot of volumetric lightmap memory though, you can probably get away with less if you don’t need perfect leak-free results.
It will awesome if we can place volumetric lightmaps accurately, by hands !
Because generated volumetric lightmaps is very rough.
This is will be huge improve graphics and gameplay !
But now UE is poor in this case
Unity3d can this
Same here. I’ve never get volumetric ligthmap density to work properly on any of my projects since 4.18. There will always be regions near the walls with low density sample distribution (just like in you screenshots) no matter what. Even with the VolumetricLightmapDensityVolume. The “Allowed Mip Level Range” Min 0 Max 0 is just ignored and it keeps behaving as there wasn’t any density volume at all.
I’ve found a workaround to the lack of high-density volumetric lightmap samples in some places where there is a mesh, but that requires building the engine from source. I just reported the issue to the Unreal Engine development team (https://issues.unrealengine.com/). The bug lies within the function “[FONT=courier new]int32 TrimBricksByInterpolationError(…)”, which is located within the file “ImportVolumetricLightmap.cpp” (Engine/Source/Editor/UnrealEd/Private/Lightmass/ImportVolumetricLightmap.cpp). The condition to remove a brick of high-density volumetric light samples is given by the following code:
if (bCullBrick)
{
HighestDensityBricks.RemoveAt(BrickIndex);
BrickIndex–;
NumBricksRemoved++;
}
…
The problem is that RMSE receives NaN (not a number) many times, thus removing a brick even if MinBrickError is set to 0 (BaseLightmass.ini). I didn’t get further into why RMSE is resulting NaN. Anyway, the only reason for the function [FONT=courier new]TrimBricksByInterpolationError() is to remove bricks. So if we want MinBrickError = 0, i.e. not removing any brick, an easy workaround is just prevent [FONT=courier new]TrimBricksByInterpolationError() from being called. This is done inside the function “[FONT=courier new]void FLightmassProcessor::ImportVolumetricLightmap()”, which is located in the same file. Instead of the instruction:
@TTimo Just after I submitted this bug, a member from Epic replied to me that the bug info I gave would be added to one of the following related bug reports:
I haven’t received any further news about this issue, and I still haven’t tested newer versions of UE to see whether or not this issue has been fixed.
The NaN error in TrimBricksByInterpolationError should have been fixed in 4.22 long time ago. If you still see weird distribution please send me repros.
