I see the JGTC runs on the USA servers:
https://www.lfs.net/leagues/818/season/1146

And the GT3 Challenge:
https://www.lfs.net/leagues/815/season/1245

It does seem like there isn't enough activity in the USA despite us having a good setup there. LFS seems to be more popular in South America. Hopefully there will be a bit more activity when we release the new update.

It's just a command that doesn't do anything but remains local. It's in the same place that local commands are processed, and does not get sent to the server.

I guess it can be seen in one of the messages that is sent out via InSim so an external program could use it for any purpose.

Quote from Bokujishin :

I haven't looked into tonemappers in-depth, just enough to know the differences as a user, but I don't remember AgX being purple

I remembered wrong, it's sort of peachy.

This was the example page I saw, about half way down the page you can select the images and the AgX ones seem to be sort of pink or peachy.

https://kronnect.com/introducing-agx-tonemapper-in-beautify-3/

I'm not saying I've discounted it, just haven't studied it enough and these examples didn't encourage me.

Quote from Drifteris :

i noticed street lamps don't cast dynamic shadows inside the car (like sun does), is that for performance or will there be an option to have it?

Our system is really not set up for shadow maps from street lights, the street lights are really just a source for ambient lighting.

Quote from Flame CZE :

It seems like the LCD brightness got fixed too?

Maybe it's because at night, the inside of the tunnel is brighter than outside, whereas it's the other way round during the day?

Maybe interesting to know that there are two exposures going on.

Other than the image-based exposure that I have been talking about, there is also a calculation based on sun height and sky brightness, which can be used to produce a roughly suitable exposure level in an SDR mode that I am currently still supporting, that doesn't have bloom or analyse the image for exposure. That gives quite reasonable results in the day and might be a helpful option for people with a low powered GPU. That calculation is very simple and done every frame even in the HDR mode (HDR is not for HDR monitors, it's just that internally we process the image using a high dynamic range).

Anyway why I am talking about that, currently that is the value that is used to set the dashboard brightness. Without that, the dashboards were EXTREMELY bright in the night, so it was a quick fix at some point in the past. Anyway as discussed earlier, it's not working well and I might do something based on getting a lighting value from your car's environment map, to simulate a light sensor, or I may take a simpler approach (for now) and just set a direct value, so the dash appears just as it does in current public LFS. I am making decisions to get to release without getting hung up on details. That would be awaiting the better dashboard support where we could allow parts of the dashboard to be illuminated by the environment.

Quote from rane_nbg :

Exposure changes look quite fantastic now, so as illuminated displays.

I notice that color tone is slightly towards netral (cool) while previous it was more towards warmer tint. I know that this is during night time, but it's the same tunnel with the same light sources. Has anything else been changed with lighting?

White balance is also based on the time of day rather than the current image. Instead of trying to analyse the image for white balance, it's simpler just to take some good values for day and night. If I used the day white balance in the night, everything would look too yellow, as we are using realistic values for the street lights.

Quote from Bokujishin :

Thanks for the night version, really nice too!
You mentioned the sky not being pitch black because of the date, and while I'm not sure of the difference between France and the UK, I was still expecting something darker, but more to the point - I think there's a bit too much ambient light outside, I believe the buildings and even the road should look much darker even with the sky's current brightness and street lights.

Well here in England, we are quite far North so in May we have short nights and there is a bit of twilight at 3am. I could do a pitch black one but don't think it's really worth it at the moment, though I can make these videos quite quickly.

By the way, I have noticed your other posts. I have tried an ACES filmic shader, might show some comparison screenshots at some point, though personally I don't like it as reality doesn't look like a film, if you see what mean.

I haven't researched enough about AgX, the ones I found did look complicated and all the example shots I saw on the internet just looked like a purple version of the image, so I wasn't sold on the idea. But I'll probably follow your link to see if the simpler version you linked to is of reasonable complexity. At the moment I am using a simple Reinhard shader to reduce the sky whiting out.

I think the tunnel lighting is quite well balanced, compared with the street lighting. Eric has set the lighting values by observation, we haven't gone so detailed as to set watts or lumens per light. But you can judge for yourself in this similar video done in the night.

EDIT: This video time is 03:14 on 4 May so the sky is not pitch dark.

Last edited by Scawen, Sun 16 Mar 2025, 10:16.

Yes, probably need a bit more practice on those bends.

The transitions were done with the real time while the video was recorded quite slowly, so that's why the transitions were too fast.

Here it is redone using the actual frame steps, so it looks as it does in game.

Quote from pärtan :

I personally think the slower exposure adjustment looks more immersive.

I'm not sure what you mean. Are you referring to a difference between the two versions?

They both have the same rate of adjustment.

The new one uses centre-weighted metering, which has two advantages:
1) Exposure based more on what you are actually looking at, instead of peripheral vision.
2) More stable because peripheral parts often have large bright or dark areas that have a bad effect on exposure.

Quote from Flame CZE :

Nice! It would be interesting to watch the same FBM tunnel drive-through video...

OK here it is. I think that:
1) The sky brightness fluctuations are reduced a bit before entering the tunnel.
2) Slightly earlier exposure reduction at end of tunnel.



Old: https://youtu.be/YL7q4t5esyI
New: https://youtu.be/jkudBQO4rfQ

A quick update today, centre-weighted metering prioritises pixels nearer the centre of the image.

At Fern Bay, the old version is too influenced by the white kerbs, so the exposure is reduced too much.


At Westhill, the new one starts to expose for the outside world more quickly at end of tunnel.

Quote from cdahmedeh :

I was tempted to say that it's some driver or hardware issue, but it's strange that both OP and I are getting very similar issues on completely different hardware.

I guess that might point to an issue in Windows itself, in the Direct3D 9 support.

One thing that hasn't changed recently is LFS itself.

Doing a search based on the error D3DERR_DEVICEHUNG...

This isn't very helpful but according to Chuck Walbourn:

Quote :

Other cases of failure are "DXGI device hung" or "DXGI device timeout". This typically means that there is either a driver/hardware bug

https://stackoverflow.com/questions/61915988/how-to-handle-direct3d-9ex-d3derr-devicehung-error#61944287

I don't think I can get involved at this time. It may be the people who write video card drivers don't do a lot of testing for Direct3D 9Ex these days, so errors might creep in.

It's better for me to continue spending my time on the D3D11 version that I am developing intensely already.

What changed a few weeks ago? Did you install a new graphics driver at that time? Can you try reverting to an older graphics driver? Nothing changed in LFS, so it sounds to me like a fault in the graphics driver or D3D.

Your thread title says "D3D device error" but you didn't include that in your report. If LFS gives this message it suggests that the instance of Direct3D 9 reported an error and had to be restarted. Could there be a problem with the D3D9 support, which is not used by most games now?

EDIT: It's possible there could be a clue in the deb.log file after the hang, a message including a D3DERR_xxx value.
Something like:

D3D device error : D3DERR_xxx

Maybe the missing part in place of 'xxx' can give us a clue.

Last edited by Scawen, Thu 13 Mar 2025, 09:56.

Yes I think that should be possible, the two screen assumption could be avoided if the primary monitor rectangle matches the desktop rectangle. I've made a note about it.

Hi, LFS has taken a guess that you have a two screen setup.

You can correct this, in the Options - View screen.

There is an option "Multiple screen layout" where you will see it is set to 1 left screen.
You can set that to zero and then it will work as a single wide screen.

Quote from Mehmetgulec :

It looks really good, but the editor also needs improvements

While I am sure your suggestions are sensible, I am not working on the vehicle editor as part of this release. the idea is to get the new version released, so I then have time to work on other things including vehicle editor improvements. Please feel free to post vehicle editor suggestions in the correct forum section: https://www.lfs.net/forum/532

Quote from lfsrm :

Great read, I'm still oddly curious about how you are going to solve the cloud sustem for the new skybox, many racing sims completely miss the mark when it comes to the visual aspect of it.

The current plan is to avoid delaying the release for clouds. I love clouds and will miss them in the early versions of new LFS. But it's a big job with many technical difficulties and that's why there will be no clouds at first, although I do want to allow completely overcast (i.e. the whole sky is a cloud).

Quote from TheRubius192FE2 :

i think the dashboard is brighter than my future (joking but hope that it gets optimized)

It's a tricky issue at the moment and that is one thing lacking in the vehicle system at the moment. We really need some way to separate the parts of the dashboard that are illuminated by the environment (in traditional dashboards that are not just a computer screen) and the other parts that are self-illuminated like lights and the modern screens. I'm sure that in real life these modern screens must adjust their brightness a great deal depending on the lighting conditions, to be visible in the day but not completely blinding in the night. In some way, all our dashboards in LFS are self-illuminated like the modern computer screens, so I think they will have to start out light-sensitive and self-adjusting, even if that is unrealistic. Awaiting the more proper dashboard support mentioned above. I've probably not explained myself very well.

It's a completely new system with D3D11 graphics, dynamic lighting, 1000Hz physics, multithreading, dynamic echo rendering. It's not a thing you could release half of.

To be honest that would be a bit like going to your BMW dealer after hearing they are developing a completely new car, and saying, I have lots of money, can you at least sell me the seats, steering wheel and some suspension parts, it would be great, I can stick it in my existing BMW that is from an entirely different era, it'll be no problem.

In fact, the whole thing goes together and has to be in one piece.

[ EDIT:

In case my rubbish analogy makes no sense, I'll say it straight: The new tracks are constructed in a new editor, for a new version of LFS. They cannot be loaded into an old version of LFS that is completely incompatible. And the new lighting system cannot be released without updated tracks. Think of it more like LFS version 2, it's completely different.

Three more points:

1) Many, many, updates from the new version HAVE been copied into the old LFS, just look at the releases of the past few years with so many updates! It's funny how people forget how much has been done in the past few years.

2) The idea is that when the new version is finally released, updates can be done more easily because I don't have to copy the same updates into two different versions of LFS and development can be finally back on track.

3) This development is a huge part of my life. If you are desperate for it to be released, try multiplying that feeling by 1000x and then you may understand how important it is for me to get it released.

end of EDIT ]

Last edited by Scawen, Mon 10 Mar 2025, 19:14.

There is no plan to release track editor in the near future. It's kind of a long term dream of something that may or may not happen. It would probably be a year or two or more of work like the vehicle mods. It's difficult to even imagine how it could work and the tracks would be distributed. It can't work like the vehicle mods. Anyway, I say this not to start a discussion about the track editor, that I cannot get involved in at this time, but to make sure people don't have false hopes. I simply added a few more features to help Eric use the track editor, as I have been doing for the last 25 years or so.

That message is probably because last time you started LFS, the headset was not connected. We need to see the openvr.log after a successful entry to VR.

In LFS there are only two options, OpenVR and Oculus Rift. I believe OpenVR is the only choice for most headsets, but all the Meta ones can use "Oculus Rift" which I should probably rename. But I'll need to know if it does work on Meta headsets... or maybe the whole option should be deleted.

To select Oculus, start LFS in the normal way (not VR) and then:
Options - View
At top of screen is a 3D button.
Click that button and you can select Oculus Rift.

It would be good to know if that works. If not, then try OpenVR again and you can paste that log result, I'll have a look and see if there are any clues in there.

Hello Racers,

We have been working hard to get LFS ready to release. As many of you know from a recent report I have incorporated the current public tyre physics into the new development version. We call it the Retro model. It's the same tyre physics but now at 1000Hz and with a self-aligning torque component that slightly improves the force feedback. The idea is to get the new graphics out without further delaying the release to await the new tyre model that is still unfinished. We also described how Eric has expanded Kyoto massively, in a way that reminds you of Westhill but with more roads and with its own character. South City is all opened up too. Eric has continued to work on South City and Kyoto.

On my side, since the start of February, it has been mainly technical work finishing loose ends from the graphical update. In a roughly chronological order, areas covered in early February include:

Force feedback (appropriate filtering to prevent spikes)
ABS (updated for 1000Hz physics updates)
Thread-related crash related to moving subobjects
Retro model updated to use new system for friction on various surfaces
AI - some bugs were present after reinstating the Retro model

Then something I found interesting that can be illustrated with screenshots. As we now use physically based rendering and high dynamic range, the exposure (brightness of the final image) has become an issue, just as it is in real life. The difference between light areas and dark areas can be quite extreme. For example if we used an exposure level suitable for outside on a sunny day, then the inside of a tunnel or a multi-storey car park would look extremely dark, even with artificial lights switched on. The exposure must be turned up in these cases and we do that by analysing the output image for brightness and constantly updating the exposure.

So far, so good, but it's a tricky thing to get right. In a typical in-car view there is the dark car interior, the bright sky, and the landscape you actually want to see. It's not good enough to take the average of the whole scene and adjust the exposure based on that. Certain areas are of interest and they need to be exposed correctly.

Two examples that produce the wrong result if we consider the whole image.
1) In an open wheel racing car, you can see so much of the sky that the exposure is reduced and the image becomes too dark.
2) In a car with restricted view of the sky and a dark interior, a lot of the image is dark and so the exposure is turned up too high.

In the FERA, an approved mod by CarlosSainz55, the overall image is quite dark so the exposure ends up too high for the scenery.
In the FOX, the overall image is bright so the exposure ends up too low.



I used a trick, to identify the scenery using the alpha channel. When rendering the sky (each frame) and the interior of your own car in a driving view, I made sure the alpha channel of the pixels was set to zero (like transparency). The alpha channel was set to not transparent when drawing the scenery. So the image that is read to create the histogram for the exposure calculation, looks a bit like this. The magenta indicates where the alpha channel is left at zero.



Now the exposure calculation can consider only the parts that are not transparent. The exposure in driving views and trackside cameras is far more usable and stable, no longer a problem and you are mostly unaware of exposure changes as you drive around. Exposure adjustments as you move into and out of darker places seem appropriate and helpful.



One thing on my list was Z-buffer issues, that I had noticed at Kyoto and have always been around, usually seen as flickering of two nearby surfaces when it's not clear to the graphics card which pixels are nearer to the viewpoint. I noticed a post by Bokujishin in which he mentioned the "Reversed-Z" method that can produce more accurate Z-buffer results with no loss of performance. It is a now well known method in which the Z buffer values go from 0 in the distance, to 1 at the near clipping plane, instead of the other way round. I tried a quick experiment that did show an improved Z-buffer and then spent a couple of days working it in properly and solving the bugs and issues that inevitably come up when you make such a change in a complex program.

While doing that, I learned about the infinite far plane, a slight change to the projection matrix that allows us to avoid cutting off pixels that are rendered beyond a certain distance, with barely any loss of Z buffer accuracy (that had already been massively improved by the Reversed-Z system). This seemed to me almost like magic, but I tried it out and it worked perfectly. It's not the usual thing to find a little code that simplifies things and provides a better result without any downside.

One of the issues that had come up when first implementing the Reversed-Z system was fog. The haze effect that helps create a sense of depth by including more of the sky colour as objects are further away. It didn't work at all but by a simple change I was able to restore a Z value to the shaders and fix the fog. But as usual, one thing leads to another and I started to look at an ongoing problem we had, with fog glowing in dark places. The short explanation is that our graphics engine doesn't really know which parts of the air are in sun or shade, so even when the camera exposure is turned up (in a tunnel or car park) the fog effect still appears as if you are looking through lit air. And as the exposure is up by such extreme values, the fog level then appears to be incredibly bright and it looks quite bad. A previous workaround had attempted to alleviate the issue by starting the fog only after a certain distance. But it wasn't a good fix: in a long tunnel you could see a 'fog line' moving down the tunnel 120 metres in front. This can be seen in the South City Work in Progress video made by Victor in 2021 (time 2:40).

120 metres was OK for car parks but not for tunnels. In the end we came up with a solution based on a comparison between the image-based exposure, and the predicted exposure if you were outside (based on a simple calculation). Now when the image-based exposure is much higher than the predicted exposure, the fog is turned down and this seems to solve the problem in a way that it it no longer perceptible as an issue. Glowing fog in dark places is no longer, while haze in open areas is unaffected.



Continuing work after that included:

Shadows: a useful optimisation and slight improvement in accuracy
VR: post-processing is now available and final image submitted as 32-bit
VR: fix for Vive Pro 2 and any other headsets with non-square pixels
Interface: shaders to show some interface elements in greyscale
Public version: Compiled public version exe for the first time
Track editor: Some minor usability improvements

Still to do:

Support for pop-up headlights and handlebar mounted headlights
- these currently are undetected and do not cast a beam
Headlight analysis to allow smaller headlights to be drawn more brightly
- currently intensity is constant so a large headlight appears brighter
Take more steps towards building an actual public version
- currently exe runs but can only get as far as track selection screen
Some amount of adjustable weather, e.g. overcast sky
- not supporting clouds for this version but some options are possible

When will it be released?

We still can't say. There are several things on our lists and new things keep popping up, so it's not possible to give an estimate.

There is no option to remove the crosshair. It should only be visible in menus anyway so should not affect your driving.

That is the first time I have heard of a loss of position tracking in any VR headset. I'd be interested to see the contents of your openvr.log file that is created when you enter VR.

But that brings me to a question, if you have a Quest 3, why are you using OpenVR? Does it not work if you select the "Oculus Rift" option? I'd be very interested to know the answer. Maybe it does work, but you don't select "Oculus Rift" because it's really a Meta Quest?

I've reinstated the round templates, allowing the new style options.

The change is that practice/qualify/race can all be specified in minutes/hours/laps without restriction.

This required some extra data in the default round format (which is stored in a different way from actual rounds). That means the old default round storage format is invalid and old round templates do not appear.

Please try it and let me know if you think it is working OK.

rane_nbg, I understand your other requests, but as I'm not really good at adding web page input systems and changing Victor's code, it's not easy for me so I can't get into it at this time while I am on a big push to get to our release.
1) The car selection option I see is a pain. At least now you can leave it as "unspecified" due to a recent change.
2) The use of a full calendar for every session in a round seems annoying, I get it. I think it should be you specify the start time of the round, and the sessions should have time offsets from that start time. In that case, the offsets could be inlcuded in the default event format.

But right now I am battling my things to try to get to a release, so I can't take on this extra confusion in the web languages that I'm not really good at. I can do these things but, as you know, it's slow progress working in someone else's system, in strange languages.

What are the files named in the data\layout folder?

You can only load them from the appropriate track configuration.

E.g. BL3 or BL3X count as a different configuration.

Hi,
I could have a look at this.
I removed it when I recently added the ability to show races in minutes (not only laps and hours). The event template system didn't support that as it uses a different type of storage.
I should probably add it back, as I see that the feature is used.

Small changes yesterday:

1) Race duration can be specified in minutes (not only hours or laps)
2) Cars can be 'unspecified' (league admin is not forced to select a car)