-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPULightmapper leaks light in situations where the CPU lightmapper wouldn't #51638
Comments
I did some testing on this, direct light seems to be correct and without leaks, but the first bounce breaks a number of things. I'm still not sure why. It may be some weird geometry or maybe something is wrong in the way we handle hits against backfaces, but there's definitely something going on that needs more investigation. |
I test it out with a simpler geometry (a cube with thick walls and a window, all conected) and the bleeding still happens |
I found one issue that GPULightmapper's triangles and bounding-boxes arrays became out-of-sync. This causes issues when the incorrect bounding-boxes were used to test the triangle in BeforeAfter |
Nice, it improved the other side effects. Any idea why the leaking might happen? I suspect that is because the UVs because even if you bake lighting around 2 boxes, the seams got some leaks |
I found another issue: rays that hit back-face triangles where counted in the bounce lighting calculations. Normally this was not the case, except for edges of planes where rays can get 'behind' the scene. This is fixed in #52618. This did not solve the leaking completely, yet I found another setting that combined with this back-face exclusion fixed it. Changing the After |
I tried a similar model in Unity and I found that intercepting geometry is not well handled so as you said, scaling the mesh in the lightmap helped in Unity too. I tried it on Godot and helped but still and issue where the seams meet. So upscaling the mesh in the lightmap helps with intercepting geometry but still an issue with the seams. |
One thing we can try is to have a cube with custom uv2 and with generated uv2s. The custom uv2 should have the problem only where the T seams meet. The generated uv2 will have in all the edges due to have every face with seems |
Just to be sure, I have two fixes and two afters. In the second fix I do not notice an issue (lightmap is scaled |
I will have a look and another scenario might help. As you mentioned this could be related to the seaming phase which I did not investigate yet. |
I think the original issue where light is leaking through edges is fixed by #52618. I will continue to investigate the other artifacts that have been mentioned. |
I haven't followed the issue too closely, but the work by @williamd67 should help get rid of all the obvious leaks. @jcostello did you have a chance to test #52618? Something that isn't clear to me yet is whether the UV2s are imported along with the model or generated by Godot at import. Keep in mind that the various UV2 islands need to be separated by at least a 2 pixel gap, otherwise there's nothing the lightmapper can do to prevent light leaks due to bilinear filtering. Godot's unrwapper should already handle this, but we don't have any way to enforce this for imported UV2s. |
At first wtih #52618 I see new artifacts in this PR. I will create 2 more specific scenarios to upload so you guys can try |
@JFonS @williamd67 I created 4 cases where I see problems with the light mapper. Here is the project you can see each case in the scene folder. https://drive.google.com/file/d/1XbWk4HVYI-fH7PyzetGVKmUQ8O5VoEOq/view?usp=sharing Test1.tscn - Hollow cube (solid) with omni light on it. Test2.tscn - Cubes with spotlight
Test3.tscn - Hut model with omnilight in it.
Test4.tscn - complex model |
Thanks @jcostello, this is exactly what I need to test more and further. I will take your model and try to find and fix the issues (or explain why they happen). |
@williamd67 no problem. Let me know if I can help you testing your progress in any way 💪 |
I retested this on master and seems that most of the things were fixed. Maybe I downloaded your PR @williamd67 but I didn't change the branch. Anyway with the first test case, when baking at medium quality (3 bounces, mesh x1) the strange AO disappear (which is how it would work) But baking it at ultru (3 bounces, mesh x1) it has an strange blob. Happens the same with x1, x2, x4 and x8 in the mesh size. |
I found that the background color leaked, which I fixed in #53081. This PR fixes the test1.scn which still showed some background color leaking when there is no dynamic light. This PR will not solve the other issues you found. I will continue to investigate those. |
Awesome. Great job @williamd67 . You are the man |
The above PR fixes the blob in scene 1 (baking at ultra, 3 bounces, 1x mesh). |
I think all the reported problems were addressed, so this issue can be closed. @williamd67 Great job tracking down and fixing all those issues :) If you want to keep improving the GPU now that you are familiar with it, I can think of a couple of improvements that may be interesting to you. The first one would be to add soft shadow support for direct lights, similar to what was done in #50184 but for the GPU lightmapper. The other one would be to improve performance a bit by adding adaptive sampling support. |
@JFonS adding a few things to the list that would be good to check out and fix and a few proposals that would be really necesary for lightmaps godotengine/godot-proposals#3213 |
@JFonS, sure I like to improve it further. I will start by investigating the issues mentioned by @jcostello. After that I will look at the proposals. |
Godot version
v4.0.dev.calinou [6f043f7]
System information
Mx Linux (Debian Based)
Issue description
The lightmapper leaks even with thick walls.
Steps to reproduce
Use the minimal reproduction project and bake the lightmap
Minimal reproduction project
GPULightmapLeak.zip
The text was updated successfully, but these errors were encountered: