Open DoctorAnsem opened 4 years ago
That sounds like an annoying problem to have encountered. How soon do you need this fixed? Currently most of my focus is going towards creating the stuff needed for lightmap baking and such (which will eventually fix this in an indirect way) but I am willing to take a break from that to investigate and fix this if it's a blocking issue for you.
It's not a major eyesore, at the end of the day. It's not bad enough that it demands immediate attention imo. Just kind of a nuisance.
This actually made me curious, if I had chosen a PBR terrain I'd probably have been forced to use all dynamic lights. Do PBR materials also obey the same limitations as to how many lights can be cast on an object? I didn't consider it before but that actually sounds like an engine limitation more than anything.
Got a situation where I hit the max number of lights cap so I did the sane thing and burned the lights into the terrain instead and marked them static. Works wonderfully for stock terrain but not a normal_ext terrain as it stands, as even with the UseZEStaticLighting set to yes they aren't actually in the terrain and the terrain is still being lit at runtime by the static lights. As you can imagine a cap of 4 omni lights will cause a lot of flickering when there's a million ordnance casting their lights on top of it.
In short, the setup is this: directional lights are both dynamic and I would prefer to keep them that way. The omni lights are static, burned into the terrain. The burned lights aren't transported into the normal_ext terrain though, also I could definitely use a Statically Lit property for the terrain so the static lights are no longer cast on it in real time. (alternatively, perhaps even preferably, this all could be resolved if the cap for number of lights could be increased, but maybe that's shooting for the moon)