It might be worth turning off tighter shadow culling in project settings advanced , rendering lights and shadows, to check whether this is a regression due to tighter culling.

If so I can investigate saturday. There is currently a known bug with directional lights in dev6, but spots and omnis no bugs currently reported.

It might be worth turning off tighter shadow culling in project settings advanced , rendering lights and shadows, to check whether this is a regression due to tighter culling.

I can confirm disabling tighter shadow culling stops the flickering

It might be worth turning off tighter shadow culling in project settings advanced , rendering lights and shadows, to check whether this is a regression due to tighter culling.

If so I can investigate saturday. There is currently a known bug with directional lights in dev6, but spots and omnis no bugs currently reported.

It might be worth turning off tighter shadow culling in project settings advanced , rendering lights and shadows, to check whether this is a regression due to tighter culling.

I can confirm disabling tighter shadow culling stops the flickering

Just tried this out, it does seem to solve the flickering issue, but apparently tighter shadow caster culling can increase performance, which is exactly what I want. Maybe tighter shadow caster culling could be set separately for each light? Maybe we could add the option's 'flickering' issue in the docs.

@catboy-catfish Don't worry, this was just to know where the problem started, is not the final solution. As lawnjelly said this will be investigated to make work with tighter shadow culling

@catboy-catfish Don't worry, this was just to know where the problem started, is not the final solution. As lawnjelly said this will be investigated to make work with tighter shadow culling

Cool cool, maybe I could make a proposal out of this

Re-opening as this is not fixed yet. Disabling was to identify the bug, not to fix.

First step was making a more usable MRP, then converting to 3.x:
spotlight_tight_cull_bug.zip

Getting clues now. It seems to be due to the spotlight being attached to the camera, at 0, 0 on the y and z axis.

The light position is therefore on the exact boundary for the top and bottom camera frustum planes, and sometimes the distance check is returning +0 and sometimes -0 due to float inaccuracy.

This may need an epsilon to prevent this edge condition.

UPDATE:
It looks like this can be solved just be increasing the colinearity epsilon a bit (I did have it set to a deliberately very low value, partly because once you increase it, you never know whether it can be lower).

Whether borderline frustum planes should be considered back facing is another matter, but this seems more like a question of slightly increasing efficiency, rather than affecting accuracy.

I'll make PR soon, I just want to check there aren't any other additions to make it more robust.