The bloom effect on the dot matrix is actually fairly realistic, at least for my eyes. I find dot matrices on motorways and on kart tracks at night have quite significant bloom. Maybe I'm overdue an eye test...

I am sure you always program as opening the possibilities, and yesterday while driving under heavy rain I thought, damn that bloom will look badass under the rain! I know it is not for anytime soon but I am sure you will nail it at some point.

Somehow to me it feels like the bloom on the dot-matrix display is too much, but the rest is fine.

I agree, the brightness seems comparable to the floodlights.

It's a similar situation with the car dashboards which have always been a bit of a cheat in LFS because they are totally self-lit like a computer screen, even if they are supposed to look like gauges with needles. For self-lit displays to be visible in the day, they are usually too bright in the night. This has become a problem now with the extreme variation in exposure between night and day.

There are good reasons to use realistic day to night lighting variation in the game but it brings with it many of the real world problems with lighting intensity and camera exposure.

I think some of these self-lit displays will need to automatically adjust their brightness for day and night. I've found a few references to car dashboard lighting with automatic adjustment to make them dimmer at night. The other solution could be physical gauges that are naturally visible in the day and have small surrounding bulbs to light them at night.

It turns out the super bright pixels were caused by the Z value for the fog calculation. On some of the oblique triangles, at some precise camera positions that weren't easy to find, the value could go way out between vertex shader and pixel shader. That caused the lerp between calculated colour and fog colour to go to extremes. Fixed by clamping the result of exp() between 0 and 1 before the lerp.

There are still some bright pixels around I can look into but they aren't causing random blooms.

My pleasure really
Glad to see that you fixed the problem, though now I'm wondering what's the cause for this depth value that goes above 1 on MSAA samples

You forgot to turn anisotropic filtering back on
The floodlights looks really stunning though. Do you have a system for the dynamic lighting on cars right now ? To have them light up properly by thoses floodlights

At end of pixel shader, this one is bad: return float4(lerp(fog_col.rgb, ret.rgb, exp(In.fog_z), ret.a);

And this one fixes the problem: return float4(lerp(fog_col.rgb, ret.rgb, saturate(exp(In.fog_z))), ret.a);

As exp(z) cannot be a negative value, the saturate is just keeping the value <= 1.

The prevented value of > 1 could only result from fog_z being negative. [EDIT: Sorry, I mean Out.oPos.z would have to be negative. fog_info.x is a negative quantity like -0.00008]. But this shouldn't be the case as the points in question were somewhere like 200m to 400m away. I suppose the calculation that sends the values into the pixel shader can come up with some crazy values if the polygon is very oblique, near horizontal relative to the view direction, and in conjunction with MSAA. My viewpoint was near one end of the BL car park, and these pixels were on some grass past the other end. I also got it coming over the brow of the slight hill before turning right to go under the bridge near the end of BL GP lap.

...I'm wondering what's the cause for this depth value that goes above 1 on MSAA samples

I've reproduced it in the public version of LFS, so you can see it for yourself if you want to, though I think you may have better things to do and this really is only for your interest if you are intrigued to see the crazy interpolation!

The attached vertex and pixel shaders show most of the world quite dark but red pixels appear if the FOGTEST value goes above 0 (which is unexpected because it is positive Z * -0.008).

The error is not usually visible but for some examples (shown in the attached screenshots) if you use window size 1888x1120 then you can see the red pixels when you use these camera positions:

I recreated the red pixels on my GTX 1060 3GB, using a window resolution of 1888x1061 (couldn't set the 1120 height, didn't let me drag it further, but the red pixels were still visible), 4x AA, 8x AF. I saw some strange flicker on the railings on the right as well, while the camera was stable and I didn't move it. I don't know if it's related or helps in any way. Highlighted both on my attached screenshot.

Seems like that with MSAA pixel shader is ran only once at pixel center and the result is duplicated for all subsamples. So it could be that the pixel center doesn't pass the depth test, but some subsample does and that then proceeds to write the PS results computed with negative z of the pixel center... VS output clearly can have negative z for some extreme cases because of numerical issues, even if in reality the vertex is far in front of the camera

I think some of these self-lit displays will need to automatically adjust their brightness for day and night. I've found a few references to car dashboard lighting with automatic adjustment to make them dimmer at night. The other solution could be physical gauges that are naturally visible in the day and have small surrounding bulbs to light them at night.

My dash in the 2018 Hyundai Elantra adjust based on ambient light level. There is a light sensor in the center of the dash all of the way forward so that it's right under the bottom of the windshield. It gives it enough light, but puts it mostly out of the view of the driver and passengers.

I wish we had adjustable traffic lights in America. There is an unlit state road in New York where in the dead of night the VTL (Vehicle Traffic Light) is absolutely blinding, to the point where you can not see past the traffic light itself. It completely floods the area with it's own light, it's so bight it illuminates the air particles, making it impossible to see past it. The speed limit for that road is 55 miles an hour.

I recreated the red pixels on my GTX 1060 3GB... I saw some strange flicker on the railings on the right as well, while the camera was stable and I didn't move it...

Thanks for the test. In free view mode the camera continues to move tiny amounts because of the camera smoothing system, so this can cause flicker if there's something prone to flickering in the view. I see on some of the railings what looks like a missing line that is sensitive to camera positions, which I think is related to unshared edges, probably due to triangle sub-splitting for the vertex lighting system. These artifacts seem to be more common with MSAA. I'm getting a lot of them (apparently missing lines) in the distance (near the red pixels) if I switch smoothly between two stored views (at the /cp locations above).

Seems like that with MSAA pixel shader is ran only once at pixel center and the result is duplicated for all subsamples. So it could be that the pixel center doesn't pass the depth test, but some subsample does and that then proceeds to write the PS results computed with negative z of the pixel center...

Thanks for the info and link. I searched for the centroid semantic mentioned there and learned about the 'centroid interpolation modifier'. In shader model 2 and 3, the modifier can be added to the TEXCOORD semantic.

My dash in the 2018 Hyundai Elantra adjust based on ambient light level. There is a light sensor in the center of the dash all of the way forward so that it's right under the bottom of the windshield. It gives it enough light, but puts it mostly out of the view of the driver and passengers.

Thanks, I'm going to try and see if my car has one of these. I know it adjusts the radio volume as I go faster which is conceptually similar.

Just wanted to say that all your comments about the off-topic discussion are bang on, it's very important that we aren't blind to the problem. We can still live our daily lives with small changes here and there, it's the little things that count towards a better environment. Nice to know we are on the same page with that.

Also, being waste and environmentally conscious can actually be beneficial economically, it's all about how you apply yourself.

Also, the LFS lighting looks great, I look forward to trying it in the future.

Hmm no, a computer regulates this with help of a speed pulse from the CAN bus system.

I said the car radio going up when there is more ambient noise is 'conceptually similar' to a dashboard getting brighter when there is more light around. That's why I put that word 'conceptually' in there. It's a similar concept. Obviously not technically related but my point is that designers who thought one thing was worth doing might also consider the other.

An optical light sensor is that old that I was playing with that thirty years ago already (Kosmos X2000 anyone?), I am surprised there is so much fuss about such a simple electronic scheme.

No-one is saying that a light sensor being used to control dashboard brightness is a highly innovative and incredible idea. The question is about how commonly the system has been implemented. You would be most helpful if you would give us some information about just how many cars have a self-regulating dash brightness and how many don't. When I code something like this into LFS, it's preferable to have some real world examples and general understanding.

Also in reality for the car designers it's probably not the two minute job you seem to imagine. The designers need to make sure the sensor is in just the right place to receive ambient light but not be affected by direct sunlight. Also they probably need to be careful so the sensor is not affected by its own resulting lighting, which could result in a feedback loop situation. The whole idea of the self-adjustment is to avoid glare and improve visibility. A poorly implemented system could end up providing the wrong light levels or suffer from flickering which would be a distraction.