Issues with lights not working using the new BVH option

[fracteed]

Godot version:
3.3 rc6

OS/device including version:
Win10, 960m

Issue description:

@lawnjelly this is the issue that we discussed on twitter.

Quite often in my topdown game, the 2 main player lights don't illuminate all mesh surfaces. These 2 lights both have shadows, one being an omni and the other being a spotlight. I don't have this issue if I turn the bvh off for rendering.

As can be seen in the start of this video of my game, when the player enters an area that should be lit by the omni and spolight, there is no illumination and then it suddenly turns back on. Towards the end of the video, shows the same thing happening, but this time the spotlight is working. When the player fires a bullet (which has an attached light), suddenly the walls and floor are illuminated by the player omni light.

bvh2.mp4

[lawnjelly]

Thanks for the report. 👍

It does sound like a simple case in the pairing that I'm missing, and will probably have to wait until we get someone by chance with a simpler reproduction case, but it's useful to know there is still a bug. I'll try and have another look through if I get chance, but these things are unfortunately much easier to fix once we have a simple case.

[akien-mga]

Is this still reproducible in 3.4 RC 1 or later?

[lawnjelly]

Just to note on this, if this is still an active bug, it is possible it is the renderer version of this: #53997 .

I need to check this when I'm working on it. This wasn't actually a bug in the BVH, more that the BVH (and octree) weren't designed to take account of masks / layers, and the client side pairing didn't cope with this properly when an object changed mask / layer while already in collision.

Am hoping to refactor this area in 3.5 to push the mask checks into the BVH by making it totally customizable via template, and this should be more efficient and less bug prone than the current system (and can replace the workaround we have in #54108).

[fracteed]

@akien-mga @lawnjelly Just tried it on rc1 and the issue is still there for me. It is strange that no one else has reported this. I am wondering if it is to do with the topdown view or how I have constructed my scenes with lots of nested spatial nodes to group various elements?

Sometimes it doesn't occur much, and other times almost straight away. If you look at this clip from the start of a level, all walls are lit, but when going a short distance and then backtracking, the walls no longer show up as lit. The 2 main lights are an overhead omni that follows the player and a spotlight attached to the player as a torch. Both have shadows on.

inifini_light_bug.mp4

[Calinou]

Related to #53374 (fixed by #54650).

@fracteed This may be fixed in the 3.4 branch, can you compile it from source and test it? (#54650 isn't included in 3.4.1rc2.)

[fracteed]

@Calinou just tried it, but alas it does not resolve the issue for me. In my case, the geometry is there, it is just not being rendered, and is completely black. Interestingly, as soon as I fire a bullet into one of these black regions or walls, everything in the area starts being rendered correctly. I am guessing that doing this is forcing the bvh to update?

[lawnjelly]

It could be a number of things, but without a minimum reproduction project, there's really little we can do except hope it might get fixed by another issue.

Note that there is currently a known deficiency with areas / statics, which should be fixed soon, see description in #55640 and #17238. This is historically the result of unclear specification regarding the collision behaviour of pairable / non-pairable objects.

There's also #55813 lighting bug, which was recently fixed (it should have be present if you built the current 3.x, rather than downloaded the artifact from #54650), but that should affect the octree too.

[fracteed]

Thanks @lawnjelly I found it too hard to reproduce in a simple scene. It might be the complexity of the scene tree that is causing the issue as there are lots of nested spatial nodes, since the levels are procedurally strung together from lots of instanced scenes.

I did try it with a fresh build from today, so that lighting bug you mentioned didn't help. As long as the bvh remains an option and can be turned off, that is fine for me. If I do get to the bottom of this I will close down this issue. The game itself if mostly on hold for moment, as I want to finish my other game first. Tentatively I will then move this game onto a more stable 4.0 next year and the joys of trying to get it to work in 4.0 :)

[lawnjelly]

Thanks @lawnjelly I found it too hard to reproduce in a simple scene. It might be the complexity of the scene tree that is causing the issue as there are lots of nested spatial nodes, since the levels are procedurally strung together from lots of instanced scenes.

Yup I remember now from when you reported it. 🙂

Sometimes it is the case that it is very difficult to reproduce, especially with pairing / RIDs, and I would still say it's better to have a bug report without MRP than no bug report at all, it lets us know there is a problem and sometimes we can work it out etc.

As long as the bvh remains an option and can be turned off, that is fine for me.

Note that this isn't guaranteed longterm as a good solution, the BVH may soon offer more advanced / better behaviour compared to the old octree in 3.x. Also in Godot 4 the octree is not available (there is currently another BVH for rendering in 4.x, but it may well be replaced by the 3.x BVH soon, it is already used for physics in 4.x). So it is important we pin down such bugs.

Another option by the way if you are compiling from source is to compile with the rids=tracked_handles option in Scons, this provides extra error checking for RIDs. I don't think it is the problem in your case (am still suspecting pairing) but it's good practice to use this build as RIDs have occasionally caused problems with objects not showing up.

[lawnjelly]

Update: This looks fixed by #55640 (@fracteed sent me closed source version to try).

[lawnjelly]

Fixed by #55640 .