2019.2.6f1 Endless Console Spam

I've had this for several releases of Unity, including 2019.2.6f1. When my terrain is at a distance, and trees are billboards, I get this error message spammed to my console several hundred times a second:

Light probe tetrahedra is malformed. Roots should be positive, but they are negative or very close to 0 due to floating point precision.
UnityEngine.GUIUtilityProcessEvent(Int32, IntPtr)




The only way I can get it to go away is to disable the terrain game object or disable Draw under the Terrain and Detail Objects checkbox.

Is this something I am doing wrong or is it a Unity bug?

 

Just reaching out to see if anyone has seen this error before? My google-fu shows this post and one other which suggests that it could be a bug. I tried rebuilding all lighting assets to no avail. It appears to be related to additive loading of a scene with light probes and the scene with probes is contained in an asset bundle.

 

Although I am not certain this is a bug (#1193857) -- I went ahead and filed a report.

 

We just started seeing this exact error yesterday (on 2019.2.0f1), although it's not endless spam, there's a fixed amount of them. But there's also no stack trace associated with them.

Very little info on the google about this.

 

In my scenario it is endless -- 27246 messages and counting after a few seconds. Screenshot above demonstrates this.

 

I can now confirm it happens when a scene is unloaded and the scene has active light probes. A workaround is to set LightmapSettings.lightProbes = null before unloading the scene. @TreyK-47, clearly an example of a bug in Unity lighting.

 

Im getting the same errors, did you ever find a fix?

 

Despite plans for a fix being back-ported to 2019.3 the errors never went away. I disabled all light probes in my scenes because the benefit was negligible. I know this isn't a helpful answer.

I suspect it might be resolved in 2020.x. What I don't understand is why they allow editor error/exception statements without a stack trace. If this error had a stack trace we could definitively point them where to look. @TreyK-47?