Quote from Evolution_R :

Looking very nice, will there be bloom at day as well?

I need to change the way the sun is drawn so it works properly with the bloom. Hoping to see some daylight results today.

Quote from nacim :

In the HDR mode I think the headlights would have been even brighter compared to the street lamps, and the bloom would have shown it.

The way I've done it depends on HDR because I'm not using a threshold. The amount of bloom I set very quickly without thinking about it much. The car headlights don't yet have a surface brightness related to their beam strength so I guess that's why their bloom doesn't seem very bright.

About the method you originally mentioned with a link to GitHub, I couldn't get much information from GitHub but your description led me to this method described by Jasper Flick:
https://catlikecoding.com/unity/tutorials/advanced-rendering/bloom/

That's basically what I've done. Is that the same as the method you were talking about? I was surprised not to be able to find any other descriptions on the net.

Quote from Amynue :

Just take a look at that hearwarming video from Peru where they use cutting edge technology to recycle trash without polluting the enviroment, we could learn a thing or two from them:
https://www.youtube.com/watch?v=wVnMBGXVVUI

A few pictures of British 'recycling':
https://duckduckgo.com/?q=uk+plastic+malaysia&t=ffsb&iar=images&iax=images&ia=images

This thread certainly took a wild turn.

Quote from chucknorris :

As lighting is the topic, then maybe it's the right time to bring this up another time Posted 3.5 years ago:
https://www.lfs.net/forum/post/1911585#post1911585

It would be really nice to finally have lights, indicators, brake-lights and also strobe-lights which are actually visible from the distance. Bloom effect is certainly a step in the right direction but may not be enough if this case.

I agree with this.

I don't have much else to say, other than keep it up. Me among a bunch of others can't wait for the release. When it does release, we all know what track I'll be playing.

Quote from Scawen :

A few pictures of British 'recycling':
https://duckduckgo.com/?q=uk+plastic+malaysia&t=ffsb&iar=images&iax=images&ia=images

Well they kinda left it there on a big pile which was a mistake since it's not very effective. To get it fully recycled you need to dump it into a river. Then the trash will be carefuly transported to the oceans via natural system of canals, where it will begin a lenghty but effective recycling process away from the country of orgin. Still a good effort UK, but you need to take some notes ✍️

Quote from Scawen :

The way I've done it depends on HDR because I'm not using a threshold.

If you are not using a threshold, what do you use ? Underexposure ?

Quote from Scawen :

The amount of bloom I set very quickly without thinking about it much. The car headlights don't yet have a surface brightness related to their beam strength so I guess that's why their bloom doesn't seem very bright.

Oh okay, that makes sense.

Quote from Scawen :

That's basically what I've done. Is that the same as the method you were talking about? I was surprised not to be able to find any other descriptions on the net.

Yeah that's the same method I was talking about. But now that you implemented that, you can look at the other github implementation (KinoBloom) to have some interesting bits added to it, like having an algorithm to compute the number of iterations depending on the radius, so that the bloom radius is independent of the resolution.

At the moment the worst problem I'm having is bright pixels caused by MSAA. I think it's related to triangles that are very oblique, then for some reason the GPU produces occasional super bright pixels that are far brighter than any vertex colour or texture colour.

Previously these have appeared as single white pixels so were not too disturbing, though they have been showing up more in night scenes. This is regardless of SDR / HDR mode, and they appear even with plain ambient diffuse lighting with direct lighting switched off. In SDR it renders straight to the backbuffer, so it's not related to render target textures. And it still happens if I switch off AF. The only thing that removes the bright pixels is switching off MSAA.

But now with bloom enabled the bright pixels have become quite a problem. They can be brighter than the sun and I'm getting quite a few of them every lap. The bloom causes them to be very noticeable.

Interesting. I would try to normalize the vertex normal in the pixel shader first, and check for holes in the geometry also. If your pixel shader just returns a uniform color, do you still have the problem ?

Quote from nacim :

Interesting. I would try to normalize the vertex normal in the pixel shader first, and check for holes in the geometry also. If your pixel shader just returns a uniform color, do you still have the problem ?

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.

Interesting read about the development of implementing bloom, and the screenshot sure looks nice. You said something about the calculation of fog, does that mean that's also coming in a new patch? (or is it already included? Haven't played LFS for a while).

Quote from Bose321 :

You said something about the calculation of fog, does that mean that's also coming in a new patch? (or is it already included? Haven't played LFS for a while).

There's already fog in public LFS but it is linear. The new version has exponential fog which is closer to reality. I'm not talking about thick fog, just the normal slight visibility reduction due to distance.

Anyway here's another couple of pictures. Note, Eric hasn't worked on the lighting in this version of Blackwood, it's just my test version with the lights switched on and things aren't really balanced correctly yet.

Quote from Scawen :

There's already fog in public LFS but it is linear. The new version has exponential fog which is closer to reality. I'm not talking about thick fog, just the normal slight visibility reduction due to distance.

Anyway here's another couple of pictures. Note, Eric hasn't worked on the lighting in this version of Blackwood, it's just my test version with the lights switched on and things aren't really balanced correctly yet.

Ah right that's what I meant indeed, cool.

Wow those two night shots are incredible! The bloom is looking amazing, especially for the lights in the distance, they have a realistic look. Keep up the great work!

Quote from Scawen :

Anyway here's another couple of pictures. Note, Eric hasn't worked on the lighting in this version of Blackwood, it's just my test version with the lights switched on and things aren't really balanced correctly yet.

It still looks VERY NICE.

Very appealing !!

It's been said a few times but, this all looks very promising, and I'll do my best to be patient for when it's all good and ready.

It'll be fun to race at night, I sadly don't get to play too many racing sims with varying conditions, so being able to do so in LFS (finally) will be something.

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.