Scawen, consider the option of adding an ambient fog effect 
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
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
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.
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).
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.
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.
I really miss that feature on my MX-5
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.
I really miss that feature on my MX-5
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
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.
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.
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.
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.
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.
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.
https://www.autoblog.com/2017/02/28/bmw-x4-toyota-tacoma-gauge-illumination/
After some mostly unhelpful internet research, I reached out to BMW and was put in touch with President of BMW Designworks Oliver Heilmer. Designworks is a design shop wholly owned by BMW in LA, and it was intimately involved with the entire process that resulted in BMW's X family of SUVs. So it's appropriate that I'm speaking to Heilmer about the X4's dashboard.
Heilmer told me that BMW's characteristic orange-red hue is generated by light at a wavelength of 605 nanometers. The color was chosen to allow the driver to clearly see the instrument cluster, but also to be able to adjust to the darkness outside the vehicle quickly after looking up. The eye doesn't tire as quickly trying to read gauges illuminated with red-orange light, he said. BMW discovered this in the 1970s, and it's been both an aesthetic trademark and a conscious ergonomic decision ever since.
Heilmer explains that the new 5 and 7 Series cars use an intelligent system keyed to a windshield-mounted light sensor for more control of the light color and intensity presented to the driver. BMW has also conducted further research that's found less difference between white and orange-red light at night than previously thought, so these newer cars will maintain neutral white dial illumination even at night (at somewhat reduced intensity), with orange-red displayed less prominently. With fully programable and digital instruments, Heilmer says, "from BMW's point of view the ideal adjustment is always displayed accordingly."
So, if dashboard lighting can be resolved, perhaps a physics release could be the next priority, maybe, please ..............
Hmm, you've got me thinking again. I haven't thought about dashboards in all that much detail.
It's only just occurred to me (or maybe I knew this before but forgot) that it seems a lot of them are backlit, rather than being lit from the front. Without going out to look in my car, I suppose it is common for the gauges to be on a transparent plate which is mainly blacked out, with light coming through in the lines and numbers that are not blacked out. And the needles of the gauges are light pipes, with light entering the needle at its base and coming out along the length of the needle.
https://duckduckgo.com/?q=dashboard+gauge+needle+lighting&iax=images&ia=images&iai=https%3A%2F%2Fi.ebayimg.com%2Fimages%2Fi%2F262815326502-0-1%2Fs-l1000.jpg
I know that the need for gauge brightness adjustment has been around for a long time, as it is a well known problem that they can be too bright when it is very dark and that can reduce your view of the road. So manual adjusters have been around a long time. But I'm not sure when it started to become common to use the apparently simple technology of a light sensor to automatically adjust the brightness, or actually how common that is in modern cars. Somehow I'm guessing it's quite normal and there may also be a manual adjuster.
Thanks for the research. Interesting that the sensor is windshield mounted rather than near the gauges. That can at least avoid any feedback from the gauges.
It's a bit frustrating that the more I actually do interact with the community and talk about what I am doing, the more certain members become frustrated because I don't appear to do what they think is the priority. And that can result in slightly sarcastic quips like your ending comment.
It's just annoying and for a moment makes me feel like I should just shut the **** up and not actually communicate. Because giving insight to the development process seems to lead to less understanding rather than more.
As you may have noticed I've recently done a massive upgrade to the lighting system that uses light levels close to those of the real world. This does have the side effect that real world problems start to make their way into the game. Every development step has these side effects that need to be resolved and that is supposed to be an interesting journey.
So, just to help you understand, here is a screenshot of how the dashboard looks right now. Take a look at that shot then tell me I am wasting my time spending a few minutes thinking about how the dashboard is lit (a minor task among the very big tasks I have been working on).
One more problem is people think that if they see me mentioning the climate in two posts in a day, that means I have spend my entire 12 hours of work thinking about the climate, when in fact it took 10 minutes a couple of times. And now you think that because I've mentioned dashboards, it has become my sole focus for several days. In fact I haven't been thinking about it much at all and I've been working on the lighting.
So it would be really cool if you could just trust my way of working, and enjoy the fact that I am talking to the community instead of keeping a big distance from them as many developers do.
Looks cool in its own way, suitable for a Tron-like theme or something out of an anime. But indeed, not good for a real world simulation :-)
Basically the backlight should always be WAY dimmer than the sun or exterior lighting, and during the day much of it would be lit by the sunlight. But that, I'm guessing, is not immediately simple with the way it's currently rendered to a surface for all dash types.
indeed an enhancement sounds welcome
For my 1989 Polo Fancy, if you switch on the lights, you have a manually adjustable green lighting ...
In the 2011 c-class, everything is automatic ... sounds adaptative but I am not really looking to it. I will pay attention this night, but I fear after 7pm French time it will be dark and by a lot, so no variation to observe.
edit : From memory in my wife's 308 from 2008, I do not think it is adpating : only a brightness level to set manually.
edit 2 : the GPS have a night mode aswell for vws in case it displays the gps...
NB : what I observe : working on brightness adaptation in modern cars while no modern cars are currently available can mean only one thing ...
I think it's just as you said, in the image above they used a translucent numbers on dash plate lit by maybe 2 or 3 lamps/leds including the central needles, it's the semi-translucency which try to uniform the light distribution (clearly not that uniform), but that's only for 80's, 90's and early 2000's cars (depend on countries), now they use maybe a full adjustable led stripe backlight.
I guess it can easily be done with some textures work, tho I don't know if it's possible to make them animated or dynamic in the LFS engine to simulate adjustable backlight.
It's a burden and a heavy task (well if it was easy we should've have it in the pub version by now), so I am 100% with you focusing on other areas (graphics), if some are not happy well they can be ignored.
I wonder if a simple constant emissive term for the lit elements + diffuse reflection from the surface * time-of-day-dependent ambient incoming light would look good? Just adjust the emissive lighting strength to look good in dark, during day the it would just disappear because physically-based ambient term should be far greater. + small amount of bloom for the needle to fake direct lightning onto the dash plate. The backlit numbers probably don't need bloom because the light is somewhat directed out and doesn't hit the front side of the dash plate.
Wouldn't it be easier to link the gauges lights to the headlights ? Like if you turn the headlights on (manually), the gauges' are dimmed.
OK my E90 LCI had it and the current F36 also has it (working on dash+navi screen). Any BMW road car would be most helpful @LFS. The Passat B6 didnt had it. This is N=3 .. 2/3 had/have it. I'm sure I've seen it in other cars as well but its not the first feature I keep in mind when I drive a car.
It also has a delay otherwise it would go loco in environments with shadow/sunlight situations
By the way, I do not know where the sensor is located. I have seen it once above the light switch... Hmm E46 maybe? [lets see]
edit2: yes.. It was my E46... Longggg ago.. Its that little transparant dot. If I putted my finger on it the display went brighter. Magic
.. Need to do something when stuck in traffic jams.. Just ignore it, time doesnt matter anymore by now.
The diffuse + emissive approach is what I expect to try at first for the main surfaces on traditional dashboards. As I say I haven't looked into it much yet (because I'm working on other things) but I think the dashboards currently work differently from the world (track) self-lit surfaces which do already use environment lighting + self-lighting. I think the dashboards use a primitive "prelit" system so they don't get lit by the environment at all and are 100% self-lit. So they need to be changed to work like the world lights, then it should start to naturally do what you are saying.
The self-lit numbers and dashboard lights will have to work a bit differently though. They will need to be brighter in the day, because they are designed (in real life) to avoid being lit by the environment at all because you don't want to see 8 for every digit.
So that's where a constant self-lighting value will go wrong, because to be visible in the day they must be quite bright, which will be too bright in the night. There's no control over where bloom appears because it's totally a post-processing effect.
Of course I could solve this all incredibly easily by simply drawing the dashboard with a brightness that is the inverse of the camera's exposure value, but that's cheating and I prefer to set brightness of these objects the same way it's done in reality. I'll probably use the equivalent of the 'windshield-mounted light sensor' to control the mainly emissive lights.
Thanks for the other replies that I haven't replied to!
I'll be keeping an eye on mine when the lighting changes next time I drive. If mine does it, it must work very well because I've never noticed it. I do notice the radio volume adjustment and the self-levelling headlights, in my BMW from 2003 which my mechanic called an 'old' car.
I'll be keeping an eye on mine when the lighting changes next time I drive. If mine does it, it must work very well because I've never noticed it. I do notice the radio volume adjustment and the self-levelling headlights, in my BMW from 2003 which my mechanic called an 'old' car.
This thread is closed
October Progress Report
(381 posts, closed, started )
FGED GREDG RDFGDR GSFDG