In the SDK docs for SU3, it is shown how to add the new flares to lights. Unfortunately, while our effects are using custom textures and not fx_0.png as the docs state is required, we are still seeing the flares added, even on interior lights. This is problematic particularly on lights that aren’t located at an actual light source (ex. floating to handle other special scenarios related to masking).
Our lights are currently set up in very specific ways, as the long-standing performance issue with light overdraw (multiple lights overlapping and taking up a large portion of the screen tanks performance) has severely limited what we can achieve, so editing the size, intensity, and softness isn’t really an option for us to disable the flare.
If it would be helpful for me to create a test/sample package to show the issue, please let me know! Thanks for the many fixes we’ve seen lately based on feedback here, it really does feel like our input matters.
Flares should not appear for interior lights so there’s something wrong indeed - would it be possible for you to send us a sample package through Private Content?
@EPellissier - No problem, I’ll ask @HughesMDflyer4 to put a package together tonight that demonstrates the issue.
@Nico - The texture specified in the .fx is unfortunately not just for the flare, but also acts as ‘mask’ to change the shape and tonality of the cast light, like a filter in front of a stage light. This can be used for non-circular spotlights, colours or gradients, or per a technique I developed a few years ago, shadows. Below are some of the mask textures we use in the .fx file which are now unfortunately generating these flares.
By placing one light source above the panel, and one floating ‘head-on’ to the panel with a mask texture that includes painted shadows, we can pretty accurately simulate shadow-casting for less dynamic elements extremely cheaply (256^ texture + 2 lights). It’s a very useful technique that I know some other developers have also started to copy in recent times, but the floating light now exhibits a rather bright flare that we can’t really control.
If removing these masks is the only way to remove the flare then we’d have to rethink how we approach lighting across our aircraft; as the dynamic lights in MSFS are simple indiscriminate surface normal + distance based with no occlusion, we have to use masks to ensure engine interiors or other areas aren’t incorrectly illuminated by light sources (e.g. the beacon light illuminating the internals of the engine).
Let me know if you have any other questions - I’ll ensure a test package is assembled that demonstrates flare behaviour in the interior + a couple of other things.
Okay, so here’s the issue: the flare texture and the mask texture parameters should never have been the same to begin with, since the two effects are unrelated.
And that means i now have no way to tell which lights should have a flare based on existing parameters.
One solution I can see is to disable flares for all interior-only lights in the new system.
But that would mean you won’t be able to have a flare on interior lights, even if you want to.
Would that be okay?
Yep, that makes a ton of sense how this has happened. I guess it would be out of scope to add an optional additional line(s) to the .fx files to control/disable this?
In any case, I think your solution of disabling flares on all interior-only lights would be a very workable solution. Out of curiosity, is the validation for interior-only done by checking ChannelInterior is true, and ChannelExterior false?
I will set flares to be on for exterior lights and off for interior lights by default, to fix this issue for all planes.
We will add a new option to force them off (for exterior) or on (for interior).
And yes, I’ll use the channel flag for that — I’ll disable flares for lights that have the ChannelInterior flag.
When not explicitly specified, these flags are set automatically based on whether the light is attached to a cockpit interior or not.
Forgot to confirm — just to be clear, after these modifications, the ‘texture’ parameter will only be used as the projected mask texture for the lighting. It will no longer affect the flare in any way.
Hey @Nico / @EPellissier , not sure if it’s of any use or if you still need it, but I’ve sent a sample project via @PrivateContent for you to test with, containing two lights - one on the exterior and one on the interior, both using a mask texture. Thanks for looking into this!
