The entire light system as it stands right now is completely inaccurate.
99% of all lights seen from the air, face downwards. Therefore all you end up seeing is the reflected result of the illumination the light casts, not the source of the light itself. In a nutshell, you don’t see the actual lightbulb/globe.
So why on earth has MSFS filled the world these magic 360° orb lights? They are incredibly unrealistic…
This was for the multi monitor support, not night light…For night light they will do continuous improvement, because it will not be perfect each time, they want to get rid of the sepia mask. It’s not easy, they need to improve the system and adjust all the time from the “technique” wise, everything change everything, reduce this, will look worst in higher altitude or in angle, add this or remove this, will broke this, this is why we are getting random change like this include bug, it’s not easy photoshop fix, until they found the right balance this will require few update.
Ps: They are few pilot in the team and many are learning lessons, Sebastian is one flying with GA.
@ExpressTomato52 Thank you for clarification.
I agree, given the length of this discussion, it shows you’re right in saying “it is not easy finding the balance”. However I believe besides implementing different techniques which are converging toward their artistic view of what this balance is, there are some actual shortcoming, if not bugs, to FS2020 night lighting which are solely related to rendering light orbs as point sprite.
The 2 problems right now with these orbs are quite simple to see and change, and won’t affect any other implementation direction much (unless there is a radically new way to make night lighting not using point sprites):
a) Not only they are larger than necessary, but their size doesn’t change with distance.
The former is probably a bug. My screenshots posted previously are showing the semi-transparent part of the point sprite (the halo) is white clipping, meaning most likely they are too bright and the clipping is turning the semi-transparent halo into a fully opaque circle, in turn, making the orbs larger than expected.
The later is probably an optimization side-effect, or just a temporary “boost” to distant brightness, but the end result is wrong. Because the light orbs size is constant regardless of the distance, this not only makes distant light relatively brighter than the nearest ones, but it is also causing a confusing soup of light in the distance. This is even more distracting and causing a lot of fuzziness in the distance, and even more so because they are displaying too large to get started. I can’t imagine how this would look in a VR headset where basically this could make you think you have a view problem needing corrective glasses.
b) Because it requires waiting incremental changes and even if they come up with an ideal solution (to them) it wouldn’t mean it would be ideal for the users, it could be helping having the means to adjust the night lighting technique parameters at the user level (if not changing among different techniques).
This is the idea expressed by @GrilledChippie here:
Not only having user configurations would permit experimenting with different approaches and sharing these settings between users, but it would also help identifying among all variations what are the most used ones, which would further help indicating whether users are really split between different ways to configuring the lights (say artistic or realistic) and in each case, what is the most agreed-on visuals.
[edited last paragraph for clarity]
Yep I second this… Problem is the light orbs. I saw a comparison screen shots above, between pre and post update-5 and it seems that the effect the lights have on the ground/buildings are the same, but light orbs got brighter post update-5 (and looks bigger / square-ish maybe primarily for us 1080p users).
Getting light orbs to get smaller over distances, and give us ability to tweak light orbs parameters (brightness, size, colour, halo, light spread distance etc) would mean a great deal for us.
If we can tweak light orbs our own, devs can just concentrate on the sepia thing and lights at rural roads. Plus, some users here who fly at night IRL can just tweak the lights themselves and share it with all of us
Floating lights in Switzerland (Interlaken). Most of them disappear as you approach them, some seem to be permanent. Zendesked it.
Submit to zendesk, floating light issue mostly appear near mountains, they fixed alot, some still remain.
I‘ve already reported it. I didn‘t know about the mountains. Interesting.
Until this gets fixed, this is a daylight simulator IMO
But in daylight also I (and others) are seeing grainy clouds and trees, LOD issue, low terrain resolutions etc… Siigghhh… Oh well
Generally I preferred the street lighting at release, but the bigger problem to me right now is BUILDING lighting, at least in big cities. Building windows should be brightly visible over the same distances as the street lights, but (I assume because they are part of the texture map), they fade quickly, with the effect that every major downtown skyline looks like a black hole amid the grid of searing street lights until you are actually among the buildings.
Even the Vegas strip - which looks much better post-USA update - is easily overpowered by the surrounding roads when the opposite should be true, and every other city is worse. Now maybe the street lights are too bright or the windows are too dim, it’s all the same to me, but the balance needs to be corrected.
Close Encounters of the Third Kind!
Explanation:
I believe this is all related to the specific LOD bug I’ve reported back in October. In turn, because the windows are fading away sooner than the walls, the illuminated windows are also fading away sooner than the walls:
There are specific LOD problems which all seem to have the same underlying cause: a difference between the distance computation and the threshold value making different objects appearing/disappearing non uniformly.
Part of the problem is the LOD ring algorithm is also factoring in the object size and I suspect the code is doing this unconditionally. This means 2 related objects (building wall + windows, small and large tree at the same distance) will be popping in/out independently.
Here is a detailed analysis of these problems from a user point of view (given the tools available):
I believe there is a bug in the FS2020 code using the Terrain LOD % slider not as a percentage, but as a square root of the percentage which is unexpected.
If this is a programming error, this could explain:
In addition:
Having both ground texture resolution and object distance controlled with a single Terrain LOD setting is a problem too. In effect, many are reducing Terrain LOD in order to reduce the number of objects (buildings, trees, photogrammetry) in the distance and save fps, but in doing so it is also reducing ground texture resolution too quickly and makes the ground appearing too fuzzy too close to the aircraft. Therefore, it would probably be beneficial you do offer 2 sliders: one for ground texture and another one for ground objects, instead of binding the two in a single Terrain LOD slider.
I’ve posted countless detailed posts about the different LOD problems in the simulator and as much I’d like to believe it might be hard to agree there is a LOD problem by principle, let alone finding what/where the problem is without a clear indication of what is wrong, I can’t help thinking there can’t be as much a difference between what I see (and report) and what is coded, so that it has taken so much time to start seeing this being listed in the latest(s) dev updates.
Hopefully the latest development update ( [BLOG] December 10th, 2020 Development Update ) is now listing several of these discussions, included this one, in the “TOP BUGS” list!
Concerning night sceneries as seen from high altitudes, especially for big cities, I made some tests over Paris using approximatly 40x40km of baked night textures generated by an algorithm I developed (that uses OSM data).
Not a big impact on performances.
Original :
After adding baked texture generated using an algorithm :
Original :
After adding baked texture generated using an algorithm :
Original :
After adding baked texture generated using an algorithm :
Other screens :
The night database I currently have covers almost all of the Europe and some parts of USA.
I stopped the generation process for the moment.
I would love to have your feedback about it !
This! Two days ago I tried to fly at night, about 12k feet above Melbourne.
Looking almost straight down in external view, I “zoomed in” and saw the light orbs illuminating low resolution terrain. It didn’t look good.
In the bigger picture, night lighting / environment also closely connected to other issues such as terrain resolution, LODs etc.
That long strings of street lights we are seeing close to the horizon far away? There should be trees and buildings blocking it from views and make it more random. Due to LOD, they’re not there… But the light orbs are.
Interesting! So basically that baked texture replaces the sepia?
Theorically yes, but not exactly for the pictures I posted. For this test I just baked the textures on a flat model. That’s why everything is hidden under it, included the airport here on the right :
At some point the flat model reaches ground level, leading to some amusing results when seen from low altitudes :
It would certainly be better if the textures were baked on the ground, but I don’t know how to do 
Merci pour votre perspicacité! Ce périph est bien embouteillé à cette heure ci 
I’ve suggested back in November using the “transportation” layer instead of the roads so as to try making the ones most used by buses and similar traffic more prominent (bus lines are along most used streets usually).
Night lighting issues still present - The community solutions - #335 by CptLucky8
Back then you’ve shown us some of your first generated street lighting which were looking promising and we can see in your post above it is looking quite good:
Have you tried using the transport layer only yet? What do you think about this?
Thank you 
“Le périph est toujours embouteillé !” 
Transport layer info would work for some big urban areas, but not for countryside nor for countries were data is lacking.
The method used to generate these tiles use road type, cadastral information, road density type by type, and POI density. With this information the algorithm knows which place is supposedly lightened, and which place is not lightened.
I compared with photos taken from space by
Thomas Pesquet astronaut and the result is very close to reality, though not perfect.
You can see here Nile Delta:
France :
Note: in the picture above all the roads of Belgium are lightened, because this is the case IRL 
It is possible to take into account country specificities by using different sets of regional parameters.
Please stay on topic of Night Lighting. This topic is generating some flags.
