Static batches broken by point lights (bug?)

I am working on bringing in some point lights into my game and I am seeing some very erratic behaviour from the static batcher. Basically if I have a group of objects that are being batched as one batch and then move a point light around to affect one or more of those objects unity I expect that unity will remove the objects affected by the light into a separate batch so now there would be two batches but this rarely happens.

In many cases the objects not affected by the light are broken into different groups, and even more often the group affected by the light are also broken into different groups also.

After running into this I made a test scene(v2019.3) with just 8 spheres (one material) and 1 point light in case there was something from my game scene causing havoc but unfortunately I am seeing the same results. The reason given is in the frame debugger is always about objects being affected by different forward lights, which doesn't make sense since with one point light there can only really be two states of lighting for these objects.

Pictures of what I am talking about attached:
bad1) first static batch has 3 unlit objects, second has 2 lit objects, 3 objects drawn solo

bad2) first static batch has 4 unlit objects, second has 3 lit objects, 1 objects drawn solo

bad3 ) first and only static batch has 2 lit objects, 6 objects drawn solo


good1) 2 static batches - all unlit in one and lit in the other


The scenario of just 2 batches is rare. Putting the light on a single object is usually the most common to get the ideal scenario (one batch one solo) but still only about 40% of the time.

I tried moving the camera around to see if this was related to draw order and indeed there is some slight variation in results from this although again there did not seem any consistency in the way this changed things. Like in some cases say I had a sphere not being batched with others and it was kind of maybe closer to the camera I could swing the camera around to look from other side of the scene so it was more at the back and nothing had changed on the batching side. Or case when another when zooming the camera out I would see the batching order shuffle around a little then zooming further go back to exactly how it was earlier. I tried turning off Camera.opaqueSortMode but that had zero effect.

Just appears to be completely random and I cannot make sense of it so any insights would be greatly appreciated.

 

From my testing of it, I have found static batching to be unreliable. It splits them based on distance from what I can tell (to prevent overdraw), as well as per-object data (light indices) so that may be why moving the camera changes them. What I am doing to get around it is just to merge meshes manually into batches using Mesh.CombineMeshes().

 

Thanks for the feedback. Personally my experience with it so far I found it was fairly reliable. That was until I tried using point lights and saw this. I am not sure to report a bug or not because it seems to obvious so I was hoping someone could shed some light on this before I did that.

So if I use Mesh.CombineMeshes() do I need a scirptable render pipepline to do frustum culling to remove renderers out of view?

 

Static Batching used to be far more predictable in Unity 4.x and before. It is the way it is now ever since 5.x onwards.

I have never got an official confirmation or some reasoning (thanks Unity!) but I think the reason is that probably the trade off of a few extra draw calls is worth it to be able to do a more relaxed static batching (that may be easier on the CPU).

Maybe after Unity shot themselves in the foot with UGUI going batching crazy to the point of causing performance problems every time anything moves, they changed their way of thinking and that resulted in the current static batching ruleset.

Or it’s a bug that no one wants (or knows how) to fix. That’s also a possibility.