Question The position of one small object completely changes light baking results

I'm not really sure how to explain this, but I've recorded some footage of what I'm seeing. I recommend watching at 2X speed, since the bulk of the time here is spent baking Realtime GI:

The basic problem is, I have an FBX of some boulders which aren't looking correct when baking the lighting. Interestingly, depending on where I put this boulder, it has a massive impact on many other objects in the scene.

Things start off looking as expected, with some test objects above, and the upper object being some of the objects in the FBX. The selected object below is the "problem" object, as I'm referring to it here:



Upon setting that selected mesh to Static, and rebaking the lighting, here's the result:



You can see that the selected object now has some lighting on it, but much of the upper object no longer has correct lighting. The rest of the video is just me moving that one object around, to try to figure out what's causing the rest of the lighting to break because of this.

To be clear, all object in the scene are flagged as lightmap static. Depending on where that selected object is placed, things could bake correctly, or they could bake completely wrong for certain objects.

I'm just wondering if anyone has any ideas on why this would be the case?

Empirically, just trying to grasp at straws here, if I view the scene in the Global Illumination Systems view, I it seems that if the large upper piece is completely contained in a single system, it essentially has next to zero lighting contribution on it. But if it's contained in a system with the other small cubes up there, it seems to bake correctly. But the system it goes into depends on what seems like randomness. If I move the small boulder around, it changes the systems of all the other objects.

When the upper section is in its own system, its directionality looks like this:



But if it's in a system with the other small cubes, it looks like this:



Things seem to be baking completely differently depending on which objects are contained within the system.

 

I played around with this a bit more, and I still don't understand it, but it does seem that certain illumination "Systems" work, while others don't. If I move an object around until it causes the Systems of the objects in the scene to change, it's likely to result in completely different lighting. Here's another (shorter) video showing that happening:

Here the select object is lit very well, and is in the same system as the other bright cubes:



But if I move that object around, to get it into a different System, the results change:



In that example, all I did was to move the selected object, yet it caused a dramatic change to several other objects. I could understand if I was blocking the lighting by moving the object, but that doesn't seem to be the case.

 

Thanks. I'll try changing those settings and see what I get.

Does it make sense, though, that depending on which System a given object ends up in, the lighting it receives can be vastly different, to the point where it seems the object sometimes receives no lighting at all? For example, in those last two screenshots I posted above, notice the three small cubes further back in the scene:



After moving a different object, the next baking results in these cubes having the following lighting:



That's where it feels like something is very broken. I'll need to experiment a bit more with this, but it almost feels like sometimes the lighting contribution is 100x smaller depending on which system an object ends up in.

 

I ended up submitting a bug report on this, bug #1286712, with a repro project that demonstrates the issue. My concern is that I'll be told this is not a bug, and it's just the way the lighting system works, but it feels so much like a bug that I felt it was right to report it.

In my bug report, I found that I was able to get some really bad lighting results eventually if I simply moved some objects around until the "system" they were in was different than their nearby neighbors. For example, notice the circled cubes in this screenshot



Those cubes are very close to other cubes, but they're in different systems:



The result is completely different lighting on those objects compared to their nearby neighbors.

In your post, you mentioned:

This doesn't strike me as a particularly "difficult" lighting scenario, but perhaps you can tell me that it is. In any case, the resulting lighting is just dramatically wrong here. Do you consider this a bug?

And to really drive this home, if I force those weight looking object into the same lighting "system" (by setting them to the same System Tag in the lightmap parameters), they'll look different:

 

And on your advice, I tried increasing the lightmap parameters. I basically turned everything up. Resolution went from 1 to 4. Irradiance Budget went from 128 to 256. Irradience Quality went from 8196 to 32768. The result was... probably worse:



You can see there's still one weird cube in the back, which is very white compared to its neighbors. You can see the cubes in the center are very white compared to their neighbors.

So, it seems like this is just not working correctly, even with fairly high values for all of these settings.

 

Thanks, that's something I figured out while trying to reproduce the issue initially, and sure, it's good to know there's an extremely manual workaround to try to address this is all else fails. However, assigning system tags to individual objects is incredibly laborious. It requires the creation of lightmap parameter assets, which are project-wide. So if I create a lightmap parameter asset to try to fix a lighting glitch in one scene, that asset will show up in the dropdown for lightmap parameters in all scenes in my project from now on. And if I start using this technique frequently, now I have many nearly identical copies of lightmap parameter assets that differ only in their system tag. Maybe if the system tag was chosen explicitly on the renderer this wouldn't be as big of a deal, but I'd be reluctant to fill my project with these assets.

The other reason the workaround isn't particularly viable is that it's unpredictable. Moving one object to a different lightmap system could cause the whole system to come up with a new way of organizing renderers into systems. So, fixing a single weird renderer could cause other renderers to be placed into systems that cause them to exhibit weird lighting artifacts.

And finally, let's say I do all of that work to manually adjust everything. It's entirely possible that simply adding one more lightmap static renderer to the scene could completely rework the system assignment of all of the renderers, and break all that manual work again. More often than not, what I've found to be an easier workaround to this is just to add more objects to the scene until the system just happens to behave nicely.

On the bright side, in all the time I've been working with Precomputed Realtime GI in the last couple of years, this issue has only come up a single time, and it was fairly difficult to engineer a test case that demonstrated it. In most cases, the lightmap system assignment that the Realtime GI system generated is reasonable. And in the unlikely case that weird artifacts are produced as a result of the system assignment, I'll probably just add some more geometry to the level in hopes that it will "reshuffle" the system assignment and all will be well.

It would be very interesting to me, however, to know why this actually happens. It's almost like each lightmap system can only handle brightness ranges in a narrow band. So, if a particularly dark object gets grouped with particular bright objects, the range compresses them both to being brighter or darker than they normally should.