Those shots looks amazing. Start to being impatient.

How does look like autox startlights look like?

Small question about the 'trackstatus lights' on the side of the track.
Do you have plans to add some functionality to them in the next patch? Maybe as a insim option.

Thx Scawen for the many previews. Keep them coming, you are doing a great job.
Also i'm curious to see the "new" South City.

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

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...

So... Xrt will open the eyes at nith update?

transparent lights cover like the XRR

That's a really great work, nice light bloom, they are looking realistic <3

Great work !! looks amazing this !!

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.

Quote from PeterN :

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.

Here's a reference to an LED display (not for cars) with an auto-adjustment.
http://www.colorlight-led.com/new/led-display-brightness-adjustment.html

EDIT: A youtube video reference for self-adjusting traffic lights
https://www.youtube.com/watch?v=vmb1vxUFmwI

Quote from Scawen :

Thank you for pointing me in the right direction again.

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

Quote from Scawen :

Anyway here's another couple of pictures.

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

Quote from Scawen :

The other solution could be physical gauges that are naturally visible in the day and have small surrounding bulbs to light them at night.

I hope when cars will be updated that they'll have physical gauges with backlighting at night

Quote from nacim :

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

I haven't narrowed it down to the actual polygons, I simply isolated the cause by editing the shaders and switching between two saved views where the problem was visible.

Just for interest here's a bit more detail:


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.

Scawen, consider the option of adding an ambient fog effect

Quote from nacim :

...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:

/cp -16074433 200686 648724 29719 712 0.0 49.2
/cp -16072587 201228 651794 29788 843 0.0 49.2

To recreate the exact window size you can use the CTRL+P command which shows the size.

I don't know if the same error appears on other graphics cards but I have a Titan Black.

I have AA 4x and AF 8x. It's easier to see with postprocessing switched off.

Another example position at that window size, I see lines of red with this viewpoint:
/cp -15986414 374202 650363 29788 843 0.0 49.2

Or I also got it in a few places just doing laps of BL in a LX6 with a maximised window.

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.

https://docs.microsoft.com/fi-fi/windows/win32/direct3d11/d3d10-graphics-programming-guide-rasterizer-stage-rules#multisample-anti-aliasing-rasterization-rules

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

Quote from Scawen :

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.

Quote from Scawen :

Here's a reference to an LED display (not for cars) with an auto-adjustment.
http://www.colorlight-led.com/new/led-display-brightness-adjustment.html

EDIT: A youtube video reference for self-adjusting traffic lights
https://www.youtube.com/watch?v=vmb1vxUFmwI

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.

Quote from MandulAA :

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).

Quote from Rejekt :

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.

I did that and it made the red pixels disappear!

Exact description: In the VS_OUTPUT structure in the test shaders (pixel and vertex) I changed the line:
float FOGTEST : TEXCOORD1; // TEST
to:
float FOGTEST : TEXCOORD1_centroid; // TEST

So now the value of FOGTEST is calculated at some point within the triangle instead of outside the triangle, so avoiding the extrapolation problem that caused the 'unexpected' values.

Quote from Dygear :

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.

TIL about centroid sampling. Thanks Rejekt for the link

Now I'm satisfied that we know the real cause of the issue
Btw thanks for the effort to reproduce it on the public build Scawen.

Quote from Scawen :

I know it adjusts the radio volume as I go faster which is conceptually similar.

I really miss that feature on my MX-5

Quote from Scawen :

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.

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

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.

Electronic scheme and the working of a Light Dependent Resistor (LDR) and photodiode explained here; https://www.electronics-tutorials.ws/io/io_4.html

Quote from nacim :

I really miss that feature on my MX-5

easy to make this aftermarket, if you really miss it

it are all cheap electronic "inventions" made decades ago already. Also the rain sensor comes from the time of a kids electronics experiment box (the same box actually).

Hi Scawen,

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.

A bit off topic but...

I usually tend to use as much light as possible from my gauges when I am driving cac... and my face is partially green...

...Or not at all! ( lol )

It is kinda same in traffic, the brighter the traffic lights, signs, other, the better...

However, when oncoming traffic appears, I hope they have as dim as possible, due I get blinded everytime when some truck drivers keep their long beams on, forcing me to take sunglasses on... at night.

Quote from cargame.nl :

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.

Quote from cargame.nl :

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.

Merc cls w219 has it. Easiest to see if you go into tunnel and come out of it.

I guess the majority of LFS cars should have normal side/edge light for dashboard (apart from VW scirocco) :



Maybe if you introduce something Like an XRT2 or FZ100 with updated architecture, you could make usage of modern sensors implementation.

I second that lfsrm's opinion.