I've done a bit of holiday work on the calendar, with a bit of help with html from my son Leo (who isn't actually an expert but knows more than me how it works).
Here is the updated calendar: https://www.lfs.net/leagues/calendar
Compare with old calendar: https://www.lfs.net/leagues/calendarOLD.php
Based on changed planned in Victor's post here: https://www.lfs.net/forum/post/1995602#post1995602
Developed from the original calendar, with inspiration from Mandula's one-week calendars and the in-game events feed.
Here is the updated calendar: https://www.lfs.net/leagues/calendar
Compare with old calendar: https://www.lfs.net/leagues/calendarOLD.php
Based on changed planned in Victor's post here: https://www.lfs.net/forum/post/1995602#post1995602
Developed from the original calendar, with inspiration from Mandula's one-week calendars and the in-game events feed.
Yes, they are blended to avoid sharp transitions. I use a spherical distance from view point rather than Z, so the transition doesn't move if you rotate the view without moving.
We don't use PCF. Softening or antialiasing is done using MSAA which is possible with ESM.
We don't use PCF. Softening or antialiasing is done using MSAA which is possible with ESM.
Well... that is to do with the way shadow mapping is done. It's all a big trick, of course, and the resulting image has shadow sharpness varying in a different way from reality. As you say, in reality the sharpness of a sun shadow decreases with the distance between caster and receiver. But the method of shadow mapping results in shadows being sharper when they are nearer to the viewer.
If you are interested enough for a long read, there is a really good article on the Microsoft website which goes through the whole method, issues and solutions. It's relevant to ours to about half way down the page.
https://learn.microsoft.com/en-us/windows/win32/dxtecharts/cascaded-shadow-maps
Our shadow maps are "cascaded shadow maps" using an implementation of "exponential shadow maps" or ESM rather than VSM described at the end of that article.
If you are interested enough for a long read, there is a really good article on the Microsoft website which goes through the whole method, issues and solutions. It's relevant to ours to about half way down the page.
https://learn.microsoft.com/en-us/windows/win32/dxtecharts/cascaded-shadow-maps
Our shadow maps are "cascaded shadow maps" using an implementation of "exponential shadow maps" or ESM rather than VSM described at the end of that article.
I haven't checked here yet but I've been looking on the internet and apparently thing may be affected by a "Steering Sensitivity" setting in the Logitech software.
https://steamcommunity.com/app/227300/discussions/0/1639787494950318456/
EDIT: Also you may be able to check if the non-linearity comes from the wheel/driver software by looking at the raw output values at the bottom right of the Options - Controls screen. Those are the raw input values that LFS receives from the software.
https://steamcommunity.com/app/227300/discussions/0/1639787494950318456/
EDIT: Also you may be able to check if the non-linearity comes from the wheel/driver software by looking at the raw output values at the bottom right of the Options - Controls screen. Those are the raw input values that LFS receives from the software.
Last edited by Scawen, .
Before I start up the other computer (with G29) to check, can I ask you to check with the official GTR cars?
They have 540 degrees of lock. You can see that in "Steering" (section of the Garage/Pits screen) some text:
Car's steering wheel turns 540 degrees (lock to lock)
I guess you see this same info text with your testing car, but please check to confirm that.
I suggest testing with an official car, or a specific mod that we all have access to, so we can compare results.
They have 540 degrees of lock. You can see that in "Steering" (section of the Garage/Pits screen) some text:
Car's steering wheel turns 540 degrees (lock to lock)
I guess you see this same info text with your testing car, but please check to confirm that.
I suggest testing with an official car, or a specific mod that we all have access to, so we can compare results.
I wrote something about that in 2021, but you replied there so I'm not sure what issue there is now.
https://www.lfs.net/forum/post/1977600#post1977600
It actually isn't very complicated. Wheel turn compensation (which is recommended to be set to max) does two different things depending on if the game controller wheel turns more or less than the in-game car wheel.
1) Game controller wheel can turn more than the simulated car steering wheel:
Perfect match is possible.
Game controller wheel stops turning (a 'stop force' is applied) when simulated car steering wheel reaches limits.
2) Game controller wheel can not turn as much as the simulated car steering wheel:
Perfect match is not possible.
Non-linear approach is implemented.
Steering wheel turn amount matches in the middle, but simulated car wheel turns more as you increase the steering angle.
NOTE: This relies on the "Wheel turn" setting in Options - Controls matching your controller wheel turn degrees. E.g. if your game controller turns 900 degrees, then "Wheel turn" must be set to 900.
EDIT: If I am missing something, or some bug has crept in, I would obviously like to know about it. But when I have checked in the past, it's all working as it should.
https://www.lfs.net/forum/post/1977600#post1977600
It actually isn't very complicated. Wheel turn compensation (which is recommended to be set to max) does two different things depending on if the game controller wheel turns more or less than the in-game car wheel.
1) Game controller wheel can turn more than the simulated car steering wheel:
Perfect match is possible.
Game controller wheel stops turning (a 'stop force' is applied) when simulated car steering wheel reaches limits.
2) Game controller wheel can not turn as much as the simulated car steering wheel:
Perfect match is not possible.
Non-linear approach is implemented.
Steering wheel turn amount matches in the middle, but simulated car wheel turns more as you increase the steering angle.
NOTE: This relies on the "Wheel turn" setting in Options - Controls matching your controller wheel turn degrees. E.g. if your game controller turns 900 degrees, then "Wheel turn" must be set to 900.
EDIT: If I am missing something, or some bug has crept in, I would obviously like to know about it. But when I have checked in the past, it's all working as it should.
Last edited by Scawen, .
A viewer is now built in to LFS, which works with all default vehicles and mods too.
You can save your skin jpg to data\skins and click the "Viewer" button near bottom left of the garage screen after creating "New colours" with the new skin. In viewer mode you will find features similar to the old CMX viewer, including a reload button.
You can save your skin jpg to data\skins and click the "Viewer" button near bottom left of the garage screen after creating "New colours" with the new skin. In viewer mode you will find features similar to the old CMX viewer, including a reload button.
I think you need to click "other controllers" then don't select one of them.
As soon as you select one of them, that is the only one it will use. If you don't select one, then axes and buttons from all of them will be available.
As soon as you select one of them, that is the only one it will use. If you don't select one, then axes and buttons from all of them will be available.
It may be you are selecting one of the devices, listed at top right of the controller options.
This has confused quite a few people. You should not select one of the devices, but instead allow all to be active.
This has confused quite a few people. You should not select one of the devices, but instead allow all to be active.
The trs files in the data\knw folder.
Here is the complete set of tracks that have changed significantly.
New versions:
https://www.lfs.net/file_lfs.php?name=SO_new_3072.zip
https://www.lfs.net/file_lfs.php?name=KY_new_3072.zip
https://www.lfs.net/file_lfs.php?name=AU_new_2560.zip
https://www.lfs.net/file_lfs.php?name=AS_new_2560.zip
Old versions:
https://www.lfs.net/file_lfs.php?name=SO_old_3072.zip
https://www.lfs.net/file_lfs.php?name=KY_old_3072.zip
https://www.lfs.net/file_lfs.php?name=AU_old_2560.zip
https://www.lfs.net/file_lfs.php?name=AS_old_2560.zip
Other tracks (BL/FE/WE/RO/LA) have not changed significantly. Changes are mostly fixes, details and textures updated for the new lighting and shadow system, so I have not generated 2D bitmaps for them.
New Westhill included for comparison with new Kyoto:
https://www.lfs.net/file_lfs.php?name=WE_new_3072.zip
Here's a zip with the old SO and KY generated as 3072.
I think they are the current public ones, but without any ambient lighting.
I didn't include the old WE as it hasn't changed significantly, other than textures and details.
EDIT: Changed to two separate zips.
https://www.lfs.net/file_lfs.php?name=SO_old_3072.zip
https://www.lfs.net/file_lfs.php?name=KY_old_3072.zip
Last edited by Scawen, .
Here are some zips with 2D top down views of updated South City and Kyoto Ring in 3072x3072 png.
EDIT: for comparison I've also generated Westhill in the same format.
https://www.lfs.net/file_lfs.php?name=SO_new_3072.zip
https://www.lfs.net/file_lfs.php?name=KY_new_3072.zip
https://www.lfs.net/file_lfs.php?name=WE_new_3072.zip
Note: some of the newly filled in areas of South City are not actually driveable. There are so many new driveable areas but to get the job finished there has to be some scenery which is not updated to full detail level.
Last edited by Scawen, .
I hope it's OK to post these route images, with the disclaimer that any configuration could be be revised or removed.
Last edited by Scawen, .
Graphics Progress Report: Kyoto updates
Hello Racers,
Eric has spent most of this year working on the Kyoto Ring environment and has expanded the driveable areas in a similar way to the Westhill track. In open configurations, you can drive around all the access roads and a new high speed karting track has been added.
To read about our progress and see some pictures of the Kyoto updates, visit the Kyoto Progress Report page.
- LFS Developers
Eric has spent most of this year working on the Kyoto Ring environment and has expanded the driveable areas in a similar way to the Westhill track. In open configurations, you can drive around all the access roads and a new high speed karting track has been added.
To read about our progress and see some pictures of the Kyoto updates, visit the Kyoto Progress Report page.
- LFS Developers
Thanks. Based on your description and the log file and the thread you linked to, I think I can see what's going wrong.
As you say, the screen resolution is 1:1 but the strange thing on your headset is this is not matched by the projection.
E.g. for left eye: GetProjectionMatrix: Left -1.635 Right 0.833 Top -1.118 Bottom 1.122
This gives X/Y of (1.635 + 0.833) / (1.118 + 1.122) = 2.468 / 2.24 = 1.102
Those values are tangents of FOV in each direction so can be safely added before the division. The problem is the result is 1.102, not 1.
For comparison with my Vive DVT, I get this result:
Resolution per eye: 1512 x 1680 giving aspect ratio 0.9
Left eye: GetProjectionMatrix: Left -1.391 Right 1.254 Top -1.473 Bottom 1.466
This gives X/Y of (1.391 + 1.254) / (1.473 + 1.466) = 2.645 / 2.939 = 0.89997
So that is basically a perfect match for the resolution aspect ratio.
So I suppose at this point that the Vive Pro 2 either has non-square pixels or uses anamorphic lenses.
I'm not sure of the solution yet, it seems that LFS will need to scale the image vertically or horizontally. I'll need to look into the code and see how it is worked out and where to insert the correction.
I'm guessing that it wouldn't be anamorphic lenses, more likely non-square pixels but it's a long time since I have encountered that. I'm thinking of Mode 13h from MS-DOS days in late 80s / early 90s.
As you say, the screen resolution is 1:1 but the strange thing on your headset is this is not matched by the projection.
E.g. for left eye: GetProjectionMatrix: Left -1.635 Right 0.833 Top -1.118 Bottom 1.122
This gives X/Y of (1.635 + 0.833) / (1.118 + 1.122) = 2.468 / 2.24 = 1.102
Those values are tangents of FOV in each direction so can be safely added before the division. The problem is the result is 1.102, not 1.
For comparison with my Vive DVT, I get this result:
Resolution per eye: 1512 x 1680 giving aspect ratio 0.9
Left eye: GetProjectionMatrix: Left -1.391 Right 1.254 Top -1.473 Bottom 1.466
This gives X/Y of (1.391 + 1.254) / (1.473 + 1.466) = 2.645 / 2.939 = 0.89997
So that is basically a perfect match for the resolution aspect ratio.
So I suppose at this point that the Vive Pro 2 either has non-square pixels or uses anamorphic lenses.
I'm not sure of the solution yet, it seems that LFS will need to scale the image vertically or horizontally. I'll need to look into the code and see how it is worked out and where to insert the correction.
I'm guessing that it wouldn't be anamorphic lenses, more likely non-square pixels but it's a long time since I have encountered that. I'm thinking of Mode 13h from MS-DOS days in late 80s / early 90s.
The aspect ratio and all other relevant info should be obtained through the interface. Maybe you could post the contents of openvr.log and we'll see if there are any clues in there?
Could you give a more detailed explanation of the skewing issue? Is it only apparent when your head is doing the roll, or does it remain visible while you hold your head in a rolled position?
Could you give a more detailed explanation of the skewing issue? Is it only apparent when your head is doing the roll, or does it remain visible while you hold your head in a rolled position?
I can't see any glitches on our performance graph, and a network test now shows very little packet loss, so I wonder if the problem has been resolved?
The graph looks clean from around 18:00 UTC on Saturday (7 December).
The graph looks clean from around 18:00 UTC on Saturday (7 December).
I've restarted the server so it should be up and running again.
I think there is still a high level of packet loss so that means our provider is responsible. It looks as if the change they made some months ago, that improved the service, is no longer effective. For some reason this changed in the past few days, so I will raise a ticket with our provider.
I think there is still a high level of packet loss so that means our provider is responsible. It looks as if the change they made some months ago, that improved the service, is no longer effective. For some reason this changed in the past few days, so I will raise a ticket with our provider.
Restarting Turkish Server
We have been asked to look at the Turkish server again.
I can see a high level of packet loss.
I am restarting the server to see if the packet loss improves. I will get results to send to our provider if the packet loss is not improved by the restart. It may take up to 20 minutes or so.
Sorry for the disruption (closing server while people are still racing).
I can see a high level of packet loss.
I am restarting the server to see if the packet loss improves. I will get results to send to our provider if the packet loss is not improved by the restart. It may take up to 20 minutes or so.
Sorry for the disruption (closing server while people are still racing).
There is a failed payment, probably details entered incorrectly. Anyway, a failed payment means no money was taken.
I'm not suggesting adding more to delay the release, but as a relatively simple thought for the future...
As it's completely enclosed, I wonder if it would be better to have a tiny 'track area' that is just a stadium and nothing else? The same kind of idea as Layout Square, but enclosed instead of open. Because then the frame rate would be as high as possible, instead of having an entire city behind the walls, that you can't see anyway.
As it's completely enclosed, I wonder if it would be better to have a tiny 'track area' that is just a stadium and nothing else? The same kind of idea as Layout Square, but enclosed instead of open. Because then the frame rate would be as high as possible, instead of having an entire city behind the walls, that you can't see anyway.
No, that is incorrect.
The path system is still there and unchanged for AI drivers.
What no longer uses the path system:
- echo map (now uses live render)
- ambient light map (now uses a global octree)
- hidden object removal (now uses global octrees)
The path system is still there and unchanged for AI drivers.
What no longer uses the path system:
- echo map (now uses live render)
- ambient light map (now uses a global octree)
- hidden object removal (now uses global octrees)
I may be wrong as I have not installed Oculus software in recent times. But I would have guessed that to run your Oculus device, you must have installed the Oculus software.
If that is the case, then it should be possible for LFS to enter VR without using Steam VR at all.
You would simply select:
Options - View - 3D
In the dialog "Options for 3D device" you select "VR system : Oculus Rift"
I'd be interested to know if that works for you.
If that is the case, then it should be possible for LFS to enter VR without using Steam VR at all.
You would simply select:
Options - View - 3D
In the dialog "Options for 3D device" you select "VR system : Oculus Rift"
I'd be interested to know if that works for you.
In what way cannot initialize? What do you see?
Maybe have a look in openvr.log
Does the HP reverb work generally in SteamVR?
Maybe have a look in openvr.log
Does the HP reverb work generally in SteamVR?
FGED GREDG RDFGDR GSFDG