Hello Racers,

Today we have an important privacy and security update.

Until now, LFS racers had a separate WEB password and GAME password. The idea was that these should be different, so your Live for Speed account would be safe even if someone obtained your GAME password. Near the end of July we learned about a leak from at least one unauthorised website where hundreds of licensed racers and thousands of demo racers had entered their LFS user name and password in past times (although that is clearly against our rules). Later, the details were obtained by someone else who provided them to some other people who proceeded to use the information to steal LFS accounts and sell them on as cheap licenses.

We were able to track down most of the stolen accounts and restore them to their original owners. Also we were fortunate to be provided with the leaked list of user names and passwords. This enabled us to track down the affected accounts and automatically change their passwords, in cases where the leaked password matched the real password. We sent an email to every affected user. Note: We follow industry standards and do not store plain text passwords. We have also deleted the list of user names and passwords that we received.

We have now implemented various security improvements to make sure this doesn't happen again.

• You now get a notification email if anyone logs in using your account.
  
• You only have one password (previously known as WEB password). This is only for the website.
  
• The old GAME password has been replaced by a new "unlock code" that you receive in an email.
  
• Your password can only be changed via an email (like the "Forgot your password" system).
  

Please note that you do need to have a valid email address in your account in order to change your password, receive an unlock code, or change your email address instantly. If you have lost access to your registered email address, there is a simple automated process to set a new one that involves waiting 7 days. This has been implemented to prevent anyone stealing an account instantly by logging in.

If you do not have access to your registered email address:

Visit your details page and click the link "send email to set new address" (although you know you won't receive the email). An email is sent to the existing registered email address, so the owner has a chance to prevent an attempted license theft. Now you can see the time, 7 days ahead, when you will be able to set a new email address without the instant confirmation. This time remains visible on your details page throughout the week.

How to get an unlock code to unlock LFS, download mods or join online hosts:

1. Log in to our website and visit your details page
   
2. Click: send email with a new unlock code
   
3. Enter the unlocking screen in Live for Speed
   
4. Copy and paste the code from the email into "Unlock code"
   
5. Click: unlock
   

The new version of Live for Speed has support for the new unlock code and other improvements. Please read the list of changes below.

Your account security:

• Always keep your registered email address up to date
  
• Only use your LFS user name and password on our official websites: www.lfs.net / www.lfsworld.net / www.lfsmanual.net
  

Four ways to get version 0.7G:

1) AUTO UPDATER - If you already have version 0.5V or later:

- Click on "Multiplayer" then "List of Hosts" in LFS and choose a download mirror.

2) MANUAL PATCH 1 (2 MB) - If you already have version 0.7E or later:

- Click HERE and save the patch installer.
- You can run the patch installer from its download location or from your LFS folder.

3) MANUAL PATCH 2 (35 MB) - If you already have version 0.6R or later:

- Click HERE and save the patch installer.
- You can run the patch installer from its download location or from your LFS folder.

4) FULL VERSION (521 MB) - If you are new to LFS or making a fresh installation:

- Click HERE to visit the download page and get the full version installer.


Changes from 0.7F to 0.7G:

Security update:

Support for the new "unlock code" (replacement for old GAME password)
Updates on the "Unlock Live for Speed" screen
- Informative message if your unlock code is not 20 characters
- Clickable links to account details page in unlock error messages
- Automatic exit from unlock screen after successful unlock message
- Error messages if there is any problem getting text from the clipboard
More informative if unlock code needs to be set or is wrong
More helpful if license has been upgraded since the last unlock
- Info about license level and unlock code detected on entry screen
- Flashes the "Unlock" or "Licensed" button if attention is required
- An appropriate message and link is displayed on the unlock screen
- For license upgrade (when code is correct) the unlock button flashes

Privacy update:

Warning if you are joining a host that will log your IP address
- Your decision to trust that host is remembered, to avoid asking you again
- You can remove the "trusted" status by clicking the "trusted" button
- List of Hosts has a new IP column to indicate hosts that log your IP address
Stops on "Join Specific Host" after you click a join link on calendar or website
- You will need to click the "GO" button as if you had clicked in List of Hosts

Interface:

List of Hosts now has 30 lines and does not show the obsolete status text
Search button in mods screen allows search by Skin ID or the 4-character name
Hover text with description when the mouse cursor is above a blob in the IP column

Graphics:

Improved vehicle view radius calculation (bounding sphere)
- LFS can more accurately detect if a vehicle is currently visible
LOD distance refers to distance from bounding sphere instead of object centre
- previous version did not work well for large objects, e.g. "track mods"
Forces view mode is no longer applied to object mods (e.g. track mods)

Force feedback:

Some steering wheels have a driver bug that reports them as "First person controller" device
Then LFS does not know it is a steering wheel, so it does not enable the steering bump stops
There is a new option, in "Axes / FF" section to manually enable steering wheel bump stops
Do not use this if your controller is not a steering wheel

VR:

Some VR headsets can have a FOV aspect ratio that is different from their pixel aspect ratio
Until now LFS did not deal with that case correctly, as seen with the HTC Vive Pro 2
LFS now uses the left, right, up, down FOV values more directly to avoid the problem

InSim:

System to allow AI drivers to be directly controlled by a local InSim program

AI drivers:

AI can now spawn in a config with an AI path even if knw has not been generated
FIX: AI now spawn in game with full fuel load if there is no path (or no knw)
FIX: Rare crash in AI code after another car spawned outside path

- LFS Developers

Last edited by Scawen, Sat 16 Aug 2025, 12:38. Reason : added "your account security" paragraph

Quote from NENE87 :

i confirm, meta quest 3 run fine for LFS

Thanks. Do you select "Oculus Rift" setting in the Options - View - 3D - VR headset dialog?

I ask as these days it's a bit strangely named in LFS and could possibly cause confusion.

Like: You want to use a "Meta Quest" so select "Oculus Rift".

Quote from Scawen :

Assuming headset is installed and tested...

Lord Scawen. Thank you! I will test this when I get home. Steam VR is not installed but I will do that. Currently at work browsing the LFS forums.I’ll let you know what happens.

Quote from versiu :

Yes u can use VR. Just go to options => view and on top change 2D to 3D, chose...

How would I go about setting it up? My friend has a Quest 2 i’m gonna borrow and test with today. Again, I know next to nothing about VR so I have no idea what i’m doing. I think i’ll tool around the internet and find some answers.

Quote from Kapurke :

Hey, guys. Having some trouble with my VR headset and LFS. Recently purchased used HP Reverb G2 and it does not work with LFS game either through SteamVR, neither through OpenComposite. Was there some kind of recent update, that killed the compatibilty or something?

What version of Windows are you running?

Windows11 24H2 update fully removes support for WMR headsets with no way to get them working without downgrading. At least presently this is the case, the author of OpenXR Toolkit (among countless other VR things) teased a project that allows WMR headsets to work in Win11 in versions where WMR has been "removed".

Last edited by gu3st, Mon 21 Jul 2025, 08:31.

Yes u can use VR. Just go to options => view and on top change 2D to 3D, chose ur headset (Oculus or OpenVR - basically any other), resolution and monitor view (preview of what u see in headset).

Hi guys. Just in the market for a VR headset. I know nothing about VR other than I want to play LFS in VR. So, my question is what VR headsets are compatible with LFS? And how would I go about setting that up?

Thanks!

Hey, guys. Having some trouble with my VR headset and LFS. Recently purchased used HP Reverb G2 and it does not work with LFS game either through SteamVR, neither through OpenComposite. Was there some kind of recent update, that killed the compatibilty or something?

If Microsoft gives me the $1000 to replace my VR headset then I'll consider upgrading.

Win11 kills my VR headset so I'm staying on Win10 for the foreseeable future.

Since the previous report in March there have been various updates. Most of the time I have worked on LFS but also had to do a few things outside of LFS.

I'm not sure how interesting it is but I can look through the list of updates I sent to Eric and add a few comments.


Towards end of March:

I worked on the render modes, which were kind of a mess and it took a while to reorganise the code a bit.

In the end I came up with 3 render modes: basic / SDR / HDR:

- basic: straight to backbuffer, no antialiasing / exposure / tonemapping
(good for lower-end GPU, uses exposure estimate based on time of day - not good in tunnels or car parks)
- SDR: uses SDR render targets, does antialiasing and exposure, no bloom or tonemapping
(exposure calculation is good but there is no glow around lights and no tonemapping to help with bright sky)
- HDR: visually the same as recent versions but now adding bloom and tonemapping in a single pass
(our best option for good GPU but there is a hit from the bloom processing and HDR render targets)

New system for different settings between VR and non-VR modes

MSAA settings "none" and 2X options in addition to 4X and 8X

Started to work on the Public build of the new version and had to work on the track selection screen. The limits are worked out differently now so some changes had to be made to align paths with map images.


Early April:

Retro tyre model:
FIX: Retro model was heating up tyres too quickly in longitudinal skids
FIX: Retro model could cause a crash with wheelspin at low speed
Implemented skid darkness from New model into Retro model

Both tyre models:
Smoke update - calculated only immediately (without temperature build-up)
Doubled intensity of dust (from dusty surfaces)
Removed the "skin temperature" thin edge on outer surface as no longer needed

Render modes:
Code cleanup allowed only downsize as much as needed for exposure in SDR mode
FIX: screen was sometimes not cleared for a few frames e.g. after pressing V

Vehicle editor:
FIX: Z buffer was not disabled when drawing wheel cross-section
FIX: Tyre cross-section was not shown if Retro model selected

Cars:
LX6 - restored public version tyre size
LX4 - restored public version tyre size / mass / engine power


Towards mid-April:

Shaders:
New compute shader included [think this was for the exposure histogram]

Exposure:
Dashboard brightness now constant regardless of exposure
Avoided black frames when changing views with V or TAB in game
- the black frames were while exposure was calculated on a hidden image
- now the screen is simply not updated during those few frames
Reduced overexposure after TAB/V/restart from dark place (e.g. tunnel)
- initial exposure attempt was then worked out from a whited out image
- the overexposed image didn't show the true excessive brightness
- issues are solved by targeting a standard brightness (after TAB/V)
Exposure is also reset and recalculated when switching Render mode
Exposure is also reset on entering or leaving Free view mode
More accurate histogram (now 256 bins - see in CTRL+E)

Graphics:
FIX: Corrupted lighting (normals) on 3D spectators with scale > 1

Misc:
Faster load of Octree when track is loading
Added progress percent for "Generating" stage

AI:
FIX: Divide by zero updating path for AI in EV (e.g. Formula XR-E @ BL1)


Early May:

I had some distractions in the second half of April but in early May sent another update:

VR: Avoided black frames when tabbing between cars in "TV in VR" view
Avoid debug message about DEFAULT lighting when car drawn as physics LOD
Added Misc option to show ms/frame instead of FPS (removed SHIFT+F5 key)
OPT: avoided setting main render target multiple times per frame
FIX: avoiding mysterious crash in SetForce after losing full screen
OUT OF BOUNDS now displayed if the spawn point is out of bounds
OPT: improved main render function saving around 0.2 - 0.3 ms per frame
FIX: Jittery freeview camera (graphics now synchronised with physics)


Summary:

I'm not intending this to try to stir up conversations, but more to illustrate all the small things I have to work on, in order to get the version finished. Most of these things, you (and I too) probably wouldn't think of but it takes a while to get everything ready after so many changes have been made in the program.

D3D11, HDR graphics, dynamic lighting, 1000 Hz physics, shadow maps, multithreading, non-path-based occlusion culling have meant a lot of changes throughout the program and while trying to get things finished, I keep encountering new things that have not been considered, or were thought of as "fix that small thing near the end" but then it is a bit harder to fix than expected.


Ongoing:

I still have to do some more work for certain headlight issues, add some weather options, finish building a releasable public version and whatever comes up in the meantime.

Eric has been doing some more work on South City and has to complete Kyoto Ring where there are still some holes around.

We still can't give a time estimate, we'll just keep doing the important things until it's ready for testing.

Tested on Quest2 and a G920 everything works perfectly, no issues (VR even seems to run a bit smoother, could be placebo though)

Quote from Silver Razor :

I'm experiencing some stuttering when having vertical sync enabled in full screen mode (same with the fps limiter enabled to 60fps in windowed mode). It happens mostly in detailed areas of certain tracks like the buildings part of the Blackwood car park. If i disable the vertical sync or fps limiter, the game seems to run with less stuttering, i'm stable over 200+ fps, topping at 270+ fps. Just in case, my cpu is a Ryzen 7 5800X.

Yeah that's kind of expected as LFS updates at 100hz so anything that's not a equal multiple will occasionally stutter. It's an issue in VR, especially as headsets are like 70-90 hz which will always seem a bit off, especilly when looking left/right

Hi, you need to give more detailed info about what kind of display this is. Lfs supports only normal monitors and VR headsets natively, however...

Quick google search shows me that a CM2 screen is just a raw display with its display controler, that usualy needs to be connected to a microcontroler with specific firmware via SPI or i2C bus which sends data to it. Then through virtual serial port (over usb connection) a microcontroler gets the actual data from a special app on PC. For example SimHub is able to receive telemetry from LFS once it is configured in cfg.txt to output outSim or outGauge packets, through LFS internal inSim protocol that utilizes UDP or TCP connection. So in principle, one can say that LFS does "support" such displays and it is possible to send data like car angles, velocity, tyre and engine temps, speed, gear, rpm and much more, but it's not such a straight forward task. In moza wheels I guess their main microcontroler stm32F407 is able to do this feature as well along with handling DirectInput - axis, buttons and ffb.

So look into SimHub program and see if it supports your display. If not, you could even use your phone and SimHub can send telemetry from LFS over your home wi-fi to it and display data in a very convenient way to look like car dash display. They have many different nice looking plugins and it works great, but you need to figure out a way how to hold your phone above your wheel base.

Last edited by rane_nbg, Mon 28 Apr 2025, 02:25.

You can use DXVK (used on Linux for converting DX to Vulkan) in Windows as well. Only thing that I ran into with testing is that it doesn't seem to work with VR.

Install is just a matter of putting the DLLs into your LFS directory. Uninstall is as simple as deleting them.

Maybe this has been posted before, remove if need be.

Yes yes, I'm unfortunately in the US. But I really want to get in on some LFS races! It's been 8 years since I've been on, and recently jumped back in and remembered why I love LFS so much. The smoothness, handling feel, it's basically CS but in driving form. Especially now with VR (which is shockingly good on LFS).

It seems all the typical events are not US based, sadly. I like cruise servers, but I really want to do some actual races. I do prefer GT cars, but I'd race anything honestly.

Can anyone recommend me a good group I could join? I lead a very busy life but do usually have downtime on weeknights and some weekends. So I couldn't race every single week, but I'd like to get in 3-5 real races a month.

Sorry for the late answer, life can be unfair sometimes...

So all work fine, no position tracking loss, if I use my normal shorcut and go to the View menu, using the 3D choice. I was connected using Meta Link and Cable, this time, not with Virtual Desktop. It work for both OpenVR and Oculus Mode, and I was able to crank Supersampling to 200%. I will prefer a shortcut parameter but that's not a big deal. Both openvr.log and riftvr.log are filled. I hope it's OK to copy paste them here as they are not that big:
-------- Openvr.log
LFSOpenVR Apr 10 2020
ProductName: Meta Quest 3
Manufacturer: Oculus
LFSVR_QueryHMD
Recommended RT size: 6656 x 3644
Left eye:
GetProjectionRaw___: Left -1.376 Right 0.839 Top -1.428 Bottom 0.966
GetProjectionMatrix: Left -1.376 Right 0.839 Top -1.428 Bottom 0.966
GetEyeToHeadTransform:
1.000 0.000 0.000 -0.034
0.000 1.000 0.000 0.000
0.000 0.000 1.000 0.000
Right eye:
GetProjectionRaw___: Left -0.839 Right 1.376 Top -1.428 Bottom 0.966
GetProjectionMatrix: Left -0.839 Right 1.376 Top -1.428 Bottom 0.966
GetEyeToHeadTransform:
1.000 0.000 0.000 0.034
0.000 1.000 0.000 0.000
0.000 0.000 1.000 0.000
IPD: 0.067
LFSVR_AcceptSharedTexture
RT size: 6656 x 3644 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6688 x 3662 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6724 x 3681 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6756 x 3699 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6788 x 3716 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6820 x 3734 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6852 x 3751 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6884 x 3769 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6916 x 3786 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6948 x 3804 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 6980 x 3821 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7012 x 3839 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7044 x 3856 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7076 x 3874 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7108 x 3891 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7136 x 3907 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7168 x 3924 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7200 x 3942 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7232 x 3959 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7260 x 3975 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7292 x 3992 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7320 x 4008 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7352 x 4025 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7380 x 4040 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7412 x 4058 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 7440 x 4073 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 9460 x 5179 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 9436 x 5166 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_AcceptSharedTexture
RT size: 9412 x 5153 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_Close

-------- Riftvr.log
LFSRiftVR Apr 10 2020
ProductName: Oculus Rift CV1
Manufacturer: Oculus VR
LFSVR_QueryHMD
Recommended RT size: 5440 x 2976
Left eye:
UpTan 0.966 DownTan 1.428 LeftTan 1.376 RightTan 0.839
Right eye:
UpTan 0.966 DownTan 1.428 LeftTan 0.839 RightTan 1.376
IPD: 0.067
LFSVR_AcceptSharedTexture
RT size: 5440 x 2976 / format: DXGI_FORMAT_B8G8R8A8_UNORM
LFSVR_Close
----------
Edit: and an additionnal deb.log if that can help:
---------- deb.log
Mar 12 11:38:04 LFS : 0.7F
Mar 12 11:38:04 timer resolution 1 ms
Mar 12 11:38:04 read config
Mar 12 11:38:04 get command line
Mar 12 11:38:04 preinit d3d
Mar 12 11:38:04 started Direct3D 9Ex
Mar 12 11:38:04 number of adapters : 1
Mar 12 11:38:04 adapter 0 - valid modes : 62
Mar 12 11:38:04 load font
Mar 12 11:38:04 -----
Mar 12 11:38:04 Init: SetPresentParams (1)
Mar 12 11:38:04 Init: CreateDevice
Mar 12 11:38:05 Init: GetRenderTarget
Mar 12 11:38:05 Init: GetDepthStencilSurface
Mar 12 11:38:05 Init: return
Mar 12 11:38:05 max texture size 16384
Mar 12 11:38:05 can do shadows
Mar 12 11:38:05 can do multi tex
Mar 12 11:38:05 load language
Mar 12 11:38:05 initialisations
Mar 12 11:38:05 tables
Mar 12 11:38:05 human system
Mar 12 11:38:05 helmet
Mar 12 11:38:05 controllers
Mar 12 11:38:05 load objects
Mar 12 11:38:05 start intro
Mar 12 11:38:05 end of initialisation
Mar 12 11:38:05 Controller 1 (Thrustmaster T500 RS Racing wheel) :
Mar 12 11:38:05 Added 5 axes
Mar 12 11:38:05 Controller 2 (T500 RS Gear Shift) :
Mar 12 11:38:05 Added 2 axes
Mar 12 11:38:06 init sound
Mar 12 11:38:21 open VR
Mar 12 11:38:47 Next LOD
Mar 12 11:38:47 Next LOD
Mar 12 11:38:47 Next LOD
Mar 12 11:38:47 Meshes : 40
Mar 12 11:42:19 open VR
Mar 12 11:44:44 shutting down
Mar 12 11:44:44 free objects
Mar 12 11:44:44 free languages
Mar 12 11:44:44 free controllers
Mar 12 11:44:44 clear light map
Mar 12 11:44:44 close sound
Mar 12 11:44:44 close VR
Mar 12 11:44:44 free humans
Mar 12 11:44:44 free font
Mar 12 11:44:44 free helmet
Mar 12 11:44:44 kill graphics
Mar 12 11:44:44 save controls
Mar 12 11:44:44 save views
Mar 12 11:44:44 save config
Mar 12 11:44:44 free mouse
Mar 12 11:44:44 EXIT

----------

I need to redo a test using Virtual Desktop, as it have several options I can tests, as it's a way to launch VR games a lot of persons are using IMHO. Far more easy.

Thanks for the report, very interesting.
The tunnel video is fabulous although it feels a bit fast.
Does the new ZBuffer will improve the ground markings and tire marks? I mean in 2D I don't notice it but in VR it feels very slightly floating like 5 or 10mm (maybe less even)...

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.

Thanks for your answer!

Not a big deal for the crosshair.

I have a Meta Quest 3 and I use Virtual Desktop in Automatic Mode, so easy, work fine with other App/Games. I'm not sure about which option I should use as I'm kind of lost between Oculus, SteamVR, OpenVR, OpenXR, etc . I don't know where to select "Oculus Rift" launch, so in fact I created a shortcut with /vr=openvr as argument. Do you advice another parameter I should try?
Content of openvr.log currently :

----------
LFSOpenVR Apr 10 2020
VR_Init failed: VRInitError_Init_HmdNotFound (108)
Hmd Not Found (108)
----------

Weird as all work fine but the position tracking...

Great read, and interesting trick with the alpha for proper auto-exposure. I do wonder though, how does it react to viewing almost exclusively the interior of a vehicle? (especially in VR if you look down and/or to the passenger side, as that could make the whole picture alpha-less). Did you maybe try weighing scenery vs sky/interior instead of masking them out entirely?
Another thing that caught my eye is the speed of auto-exposure in the video (really nice to watch by the way, I like the whiteout at the end of the tunnel): it seems a bit too reactive at times, e.g. when driving in and out of the shadows before entering the tunnel, leading to some "blinking" of the sky; the dash also unfortunately becomes illegible, and I assume night driving will result in similar (or worse) lighting scenarios.

Still on the subject of lighting, I'm wondering what tonemapping you are using, and whether a different approach would help with the dynamic range (a popular tonemapper in games being ACES, but I would also like to suggest AgX, as it tends to look more realistic (the Godot Engine made a slightly simplified implementation that is more suited to games than the full version).

Feel free to use us as bug hunters when you can get a test patch out , I'm sure some of us would be more than willing to help beyond just enjoying the shiny update (although many would likely just complain about the crashes instead).

Last edited by Bokujishin, Mon 10 Mar 2025, 17:18.

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?

Hi Guys,
I'm able to play in VR, but this crosshair is not needed as mouse work fine, can I remove it?
Also, more problematic, the VR view in the car is limited to 3 degree of freedom (Quest 3 with Virtual Desktop in SteamVR mod), I mean if I move my head E.g. forward, all the car move too forward, so I stay at the same distance to the dashboard (Am I clear?) LFS is the only Sim I have this issue...
Thanks in advance!
Laurent

I did test it running VR on a Valve Index. No issue.