One is RGB, the other is RGBA.
You need to end the filename in _ALP for the RGBA to work, and you need _ALP to not be there for RGB to work.
IE, if you have an RGB image called texture1.png and you convert it to RGBA, it must be renamed to texture1_ALP.png before it'll work properly in the editor.
You need to end the filename in _ALP for the RGBA to work, and you need _ALP to not be there for RGB to work.
IE, if you have an RGB image called texture1.png and you convert it to RGBA, it must be renamed to texture1_ALP.png before it'll work properly in the editor.
have problem with png picture to mod
Could someone explain what happened to the lamp photo that it won't load in Live for Speed Editor? If someone could fix it, of course the author would be a contributor to the mod.
regards.
problem with 2nd picture
regards.
problem with 2nd picture
Some AI racing games use that way for racing. Codemaster. EA Sports. and sometimes Beamng.drive (Depending on the car they're using.)
And Full Physics...
we can re-create Similar physics. Just Like rFactor.
They don't use the player Physics but a different Physics that isn't the same. but on track it's quite the same. but what it's the difference? They do more overtakes. More Mistakes. More Crashes. and Faster AI.
and of course for S3 Mods. they gonna keep the LFS Physics. or a Custom Made Physics which it can be made on the LFS Editor.
And About Rolling start and formation. The cars will have 2 types of System for that.
1. The normal AI.
2. Forced AI.
The normal AI will be the same as the LFS. Just driving and trying to win.
Whoever the Forced AI. will NOT apply Physics. The cars will have 2-4 Different Lines for the Rolling start. to NOT cause a crash. and after the Green flag the Normal AI will be switched up again. and the setups won't be applied until the green flag.
Why not Physics?
They probably will glitch out after spawning. and preventing crashes.
Why not Applying Setups?
Just imagine 0 Downforce. No pressure and skinny tires and scrapping suspension. the cars will go straight into the barriers. to avoid that. we won't apply Setups until the green flag it's out.
And Full Physics...
we can re-create Similar physics. Just Like rFactor.
They don't use the player Physics but a different Physics that isn't the same. but on track it's quite the same. but what it's the difference? They do more overtakes. More Mistakes. More Crashes. and Faster AI.
and of course for S3 Mods. they gonna keep the LFS Physics. or a Custom Made Physics which it can be made on the LFS Editor.
And About Rolling start and formation. The cars will have 2 types of System for that.
1. The normal AI.
2. Forced AI.
The normal AI will be the same as the LFS. Just driving and trying to win.
Whoever the Forced AI. will NOT apply Physics. The cars will have 2-4 Different Lines for the Rolling start. to NOT cause a crash. and after the Green flag the Normal AI will be switched up again. and the setups won't be applied until the green flag.
Why not Physics?
They probably will glitch out after spawning. and preventing crashes.
Why not Applying Setups?
Just imagine 0 Downforce. No pressure and skinny tires and scrapping suspension. the cars will go straight into the barriers. to avoid that. we won't apply Setups until the green flag it's out.
Last edited by Antonnio Giovannazi, .
Both Macan GTS and custom got some important work especially in the interior.
Custom macan got new rims & seats:
In editor:
Interior for the custom macan (leather texture got changed, added alcantara texture in some parts, added colorable stitch):
a major update in the centre for both custom and gts:
changed the carbon in the interior to aluminum for the current macan gts:
Custom macan got new rims & seats:
In editor:
Interior for the custom macan (leather texture got changed, added alcantara texture in some parts, added colorable stitch):
a major update in the centre for both custom and gts:
changed the carbon in the interior to aluminum for the current macan gts:
Mercedes-Benz C218
Hi there , this it's my C218 from : https://sketchfab.com/3d-models/mersedes-cls-63-a6453fa2846a4d62b869aecfc0276da2
This car develops around 580 hp and 800 nm of torque.
This project was done in 2 days... I took the mod from Sketchfab, reduced it in a 3d modeling application, added the project to Lfs Editor. The reduced mod in the application had around 80k tris, and I reduced the details on Lfs Editor to 65k tris, then I started mapping, texturing the car and its details. I made a new set of rims specific to this model using a Blueprint, repaired the small holes left from the reduction of details, then started working on the handling.
This mod is a work in progress, so there will be more updates.
Rim Blueprint : https://www.oemwheelshop.com/cdn/shop/products/115102_01_700x700.jpg?v=1704353697&hl=ro-RO
(I'm not at my PC right now and I don't have access to the pictures of how the mod was created, but I'll leave here 3 pictures sent to a friend)
This car develops around 580 hp and 800 nm of torque.
This project was done in 2 days... I took the mod from Sketchfab, reduced it in a 3d modeling application, added the project to Lfs Editor. The reduced mod in the application had around 80k tris, and I reduced the details on Lfs Editor to 65k tris, then I started mapping, texturing the car and its details. I made a new set of rims specific to this model using a Blueprint, repaired the small holes left from the reduction of details, then started working on the handling.
This mod is a work in progress, so there will be more updates.
Rim Blueprint : https://www.oemwheelshop.com/cdn/shop/products/115102_01_700x700.jpg?v=1704353697&hl=ro-RO
(I'm not at my PC right now and I don't have access to the pictures of how the mod was created, but I'll leave here 3 pictures sent to a friend)
Last edited by Eduard.kbg, .
This is not possible to set up in LFS editor - ABS yes or no,no other options available to set up ABS function.
started doing a custom macan with a V8 few days ago, and that's how it looks so far:
Nothing is done in the interior or the rims yet.
All work/modifications made in LFS Editor. No blueprints, just some references / irl pictures.
Inspired by / source: CMST Tuning
Nothing is done in the interior or the rims yet.
All work/modifications made in LFS Editor. No blueprints, just some references / irl pictures.
Inspired by / source: CMST Tuning
Last edited by M7md1467, .
Interesting project - I've always been kinda fan of this track,still remember old CART races there and actually the 1st live CART race I ever saw was run there,so I'm deffinitelly curious about this. Quick check and compared to Google Earth measurements it seems to be on scale,however the layout itself does not seem to be well made as the track consists of lines,which probably are not the best track limits enforcement,while the lots of the tyre barriers seem to be just a waste of objects (we're still quite limited in layout editor unfortunatelly). Maybe would be better if you would use the long 10m speed bumps as track limits (the 6m for turns)? Could also save few objects as these are 2m longer than lines while it would also enforce track limits better.
Too bad LFS limitations force to move finish line...
Too bad LFS limitations force to move finish line...
The list of changes from D48 to D51 includes:
In my case the stanchions and the lowers coincided only at one and only one ‘lowest wheel height’ : -115mm, which makes the front too high and to get stance right must set front too soft. By the way, this height is exactly at the intersection of the head angle line and the vertical axle projection.
Oddly enough, that ‘lowest wheel height’ (-115mm) must be only in the first set. Proper value can be set in the second set without misalignment.
But! If you delete the first set, the second set (which allowed ‘lowest wheel height’ to be freely adjusted) will turn on and fork will immediately fall apart even if no settings are touched
All dimensions in LFS Editor are set correctly:
caster — 20.5°, horizontal trail reduction — 43mm, fork offset — 40mm, ground trail — 72mm, also axle coordinates -0.38 and +0.68.
Two suspension tab screenshots with different wheelbase: 1.103m [soft] and 1.079m [normal].
In my case the stanchions and the lowers coincided only at one and only one ‘lowest wheel height’ : -115mm, which makes the front too high and to get stance right must set front too soft. By the way, this height is exactly at the intersection of the head angle line and the vertical axle projection.
Oddly enough, that ‘lowest wheel height’ (-115mm) must be only in the first set. Proper value can be set in the second set without misalignment.
But! If you delete the first set, the second set (which allowed ‘lowest wheel height’ to be freely adjusted) will turn on and fork will immediately fall apart even if no settings are touched
All dimensions in LFS Editor are set correctly:
caster — 20.5°, horizontal trail reduction — 43mm, fork offset — 40mm, ground trail — 72mm, also axle coordinates -0.38 and +0.68.
Two suspension tab screenshots with different wheelbase: 1.103m [soft] and 1.079m [normal].
Improving and adding sounds
Hello everyone. I've been trying to improve the sounds in a simple way for LFS for a while now.All this with external programs-(Some Windows sound improvements).Without having to modify almost anything in the game.
1:I've added the hazard lights sound, the handbrake, and the click of the lights button:(OBS).
2:Modifying the equalization:The FXSound program gives the cars a more metallic sound and, from my point of view, a more deep and enveloping.
3:Some things from the Simhub program to make the dashboard more realistic.
(Only change in LFS)In this mod I changed the V6 engine to V8 From LFS Editor.
1:I've added the hazard lights sound, the handbrake, and the click of the lights button:(OBS).
2:Modifying the equalization:The FXSound program gives the cars a more metallic sound and, from my point of view, a more deep and enveloping.
3:Some things from the Simhub program to make the dashboard more realistic.
(Only change in LFS)In this mod I changed the V6 engine to V8 From LFS Editor.
Adjustable Boost Pressure on Setup Tab
As some know, both drift and race cars have adjustable turbo pressure depending on the condition they're put on, for example, Porsche 935 K3 1979 had 1.5bar for qualifying with an output of 800bhp and a 1.3bar setting for race making around 670bhp for better reliability.
Since there's a lot of retro race cars like the FEND MUSTING GR5 and the PORSHELL 539, i feel like it would be nice to be able to edit this setting while on the in-game setup tab, not only it would be more realistic than just air intake restriction.
Maybe not all mods should allow it, hence why i tought this could also be included in the "Allow" tab on the LFS Editor. <adjustable_turbo_pressure=YES/NO>
Hopefuly we get this in the future, i feel like this would be a nice addition to the in game setups and also a more realistic approach to the "restriction rules".
Since there's a lot of retro race cars like the FEND MUSTING GR5 and the PORSHELL 539, i feel like it would be nice to be able to edit this setting while on the in-game setup tab, not only it would be more realistic than just air intake restriction.
Maybe not all mods should allow it, hence why i tought this could also be included in the "Allow" tab on the LFS Editor. <adjustable_turbo_pressure=YES/NO>
Hopefuly we get this in the future, i feel like this would be a nice addition to the in game setups and also a more realistic approach to the "restriction rules".
It would be wonderful if the licensing allows for it to be included in LFS, I sure am hoping to see interest from Scawen/Eric. More real life tracks can only improve the LFS experience.
With that said, even if the data were to be made available to them right now, I assume we're looking at several years down the line for Eric to be able to make it into a proper LFS track (since he already has to update existing tracks environments, and we don't know about possible plans for new cars) - unless a mod track editor is made available, but that too would require a lot of work before it could be released.
With that said, even if the data were to be made available to them right now, I assume we're looking at several years down the line for Eric to be able to make it into a proper LFS track (since he already has to update existing tracks environments, and we don't know about possible plans for new cars) - unless a mod track editor is made available, but that too would require a lot of work before it could be released.
Hi Scawen! Do you planing to increase the objects limit in the LFS Editor in game, now we have 3k limit , any chance to increase it ??
No need for rain for now, only a track editor. Create your own fork of "Historic Lemans". From my point of view, we need a track editor, you need to create a thread with a proof of your work and only the developer can add the track to the official lfs release.
Alright, time to announce a new project with GodotInSim: GIS Hub (as in GodotInSim Hub).
This is an application, built on GodotInSim of course, that aims to become a small ecosystem, an InSim manager if you will; you get a GUI with tabs, where each tab corresponds to an InSim module, and therefore each module can provide its own user interface based on Godot Control nodes, as well as its own logic, based on a packet subscription system: modules initialize by telling the hub which packets they want to handle, and optionally which packets they want to ignore. They can also request notifications for packets sent by other modules, as well as the list of active modules.
As a bonus, all modules share the same InSim connection, so it can be interesting to make modules more specialized instead of having a very broad scope, without risking going over the maximum 8 connections LFS supports.
The idea here is to allow multiple people (or myself
) to work on smaller-scale projects, and potentially use functionality from other modules where it makes sense (although I hope this won't make dependencies too big of an issue).
To allow for a single InSim connection, I start a separate instance of the app, create a TCP server on it (default port 29990), and connect the hub to it. The server connects to InSim and relays packets to and from the hub, which then dispatches them to the modules.
Since each module only needs to implement a few GISModule functions, but is completely free otherwise, you can even manage your own InSim connection if you want to bypass the server, while still being able to monitor other modules. OutSim and OutGauge, as well as InSimRelay, must be managed at the module level.
As a very quick example, here is a simple log module, which writes the contents of packets it receives, packets sent by other modules, and formats messages in a nicer way instead of the raw data: (yes, the messages are just tests and sent by the log module itself)
The InSim-managing server also includes a log, but writes it to a file instead, which means that even if the hub crashes because of a module error, packets keep being logged by the InSim connection, and the hub can reconnect to the server when restarted.
I am planning to make a few "core" modules, that would always be active, but other modules would be discovered at runtime and enabled or disabled dynamically by the user. Currently planned core modules include Hub functionality (general settings, InSim setup) and Player Management (UCID and PLID lists - this might be included in the Hub module instead), I am open to suggestions for additional core features (something that the vast majority of InSim apps could use). I will also try to convert my own projects to modules and distribute them along with this app.
Speaking of which: modules need to be exported as a Godot pck file (you need the Godot Editor for this), and placed in the modules folder next to the executable. The pck should be contained in a folder of the same name (modules/my_module/my_module.pck), to avoid conflicts in the filesystem after importing multiple modules.
Security: Modules have access to all Godot functionality, including potentially dangerous functions, like deleting files or simply executing any kind of code - you should only download pck files from trusted sources (ideally directly from the author's online code repository like GitHub or GitLab), and not from random people (that would be like launching .exe files random people send you).
GIS Hub features:
I will probably repeat some of this, and include more details about actually creating modules, in a dedicated thread and in a link to the GitLab repository I'm hosting this on, once I have improved basic functionality and tested it properly.
This is an application, built on GodotInSim of course, that aims to become a small ecosystem, an InSim manager if you will; you get a GUI with tabs, where each tab corresponds to an InSim module, and therefore each module can provide its own user interface based on Godot Control nodes, as well as its own logic, based on a packet subscription system: modules initialize by telling the hub which packets they want to handle, and optionally which packets they want to ignore. They can also request notifications for packets sent by other modules, as well as the list of active modules.
As a bonus, all modules share the same InSim connection, so it can be interesting to make modules more specialized instead of having a very broad scope, without risking going over the maximum 8 connections LFS supports.
The idea here is to allow multiple people (or myself
) to work on smaller-scale projects, and potentially use functionality from other modules where it makes sense (although I hope this won't make dependencies too big of an issue).To allow for a single InSim connection, I start a separate instance of the app, create a TCP server on it (default port 29990), and connect the hub to it. The server connects to InSim and relays packets to and from the hub, which then dispatches them to the modules.
Since each module only needs to implement a few GISModule functions, but is completely free otherwise, you can even manage your own InSim connection if you want to bypass the server, while still being able to monitor other modules. OutSim and OutGauge, as well as InSimRelay, must be managed at the module level.
As a very quick example, here is a simple log module, which writes the contents of packets it receives, packets sent by other modules, and formats messages in a nicer way instead of the raw data: (yes, the messages are just tests and sent by the log module itself)
The InSim-managing server also includes a log, but writes it to a file instead, which means that even if the hub crashes because of a module error, packets keep being logged by the InSim connection, and the hub can reconnect to the server when restarted.
I am planning to make a few "core" modules, that would always be active, but other modules would be discovered at runtime and enabled or disabled dynamically by the user. Currently planned core modules include Hub functionality (general settings, InSim setup) and Player Management (UCID and PLID lists - this might be included in the Hub module instead), I am open to suggestions for additional core features (something that the vast majority of InSim apps could use). I will also try to convert my own projects to modules and distribute them along with this app.
Speaking of which: modules need to be exported as a Godot pck file (you need the Godot Editor for this), and placed in the modules folder next to the executable. The pck should be contained in a folder of the same name (modules/my_module/my_module.pck), to avoid conflicts in the filesystem after importing multiple modules.
Security: Modules have access to all Godot functionality, including potentially dangerous functions, like deleting files or simply executing any kind of code - you should only download pck files from trusted sources (ideally directly from the author's online code repository like GitHub or GitLab), and not from random people (that would be like launching .exe files random people send you).
GIS Hub features:
- Modular InSim application with a TCP server managing packet input/output to/from LFS
- Very basic crash protection for the InSim server, running in a separate process from the hub (does not prevent loss of functionality from the modules)
- Allows for cohabitation of many independent modules while "consuming" only one InSim connection
- Full InSim, OutSim, OutGauge and InSimRelay support on a per-module level
- Module communication: modules can request the list of active modules, as well as monitor packets sent by other modules
- (WIP) GIS Hub options, InSim setup
- (Planned) UCID and PLID management
- (Other) Open to more suggestions (for actual core features)
- (Done) Packet logs
- (Planned) Message helper (write or copy/paste Unicode characters, change selected text's color, send as user or local message)
- (WIP) Telemetry
- (WIP) Race Stats
- (WIP) Lap Delta (a certain someone has been persistently asking for this since I showed a proof of concept last summer , even though other apps already do this)
- (Maybe) Setup Validation Tool (not sure it warrants a module as it does not actually use InSim (it would if setups could be sent via InSim), but why not)
I will probably repeat some of this, and include more details about actually creating modules, in a dedicated thread and in a link to the GitLab repository I'm hosting this on, once I have improved basic functionality and tested it properly.
Last edited by Bokujishin, .
All that in lfs editor huge respect+1000 🥶
I think I can speak for the community, that these updates are a powerful reminder of how development should be done. Excellent documentation, your candor and realism at all angles is incredibly thoughtful and appreciated. Dedication to quality and making a working product is a dying art, and we only find it in awesome independent developers like you all.
We are so excited for the future of LFS, good on you dev team, keep up the good work, keep the faith, we are with you ❤️
ps: thank you for the modding system, it's truly a pleasure to be able to enjoy this and to be able to contribute to it. If we can see a track editor in the future, I know it's a lot of effort, but you can figure it out once you get time to sit down with the problem.
The juice is worth the squeeze, great updates, keep going 🔥
We are so excited for the future of LFS, good on you dev team, keep up the good work, keep the faith, we are with you ❤️
ps: thank you for the modding system, it's truly a pleasure to be able to enjoy this and to be able to contribute to it. If we can see a track editor in the future, I know it's a lot of effort, but you can figure it out once you get time to sit down with the problem.
The juice is worth the squeeze, great updates, keep going 🔥
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
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).
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 looks really good, but the editor also needs improvements and I would say it is lacking even for this version.
_ALP indicator overlay is not allowed.
Indicator overlay maximum size 512x512
If it is possible for it to work, we should be offered this option
INDICATOR TYPE / Analogue or Digital
A 3D cursor for the analogue display to which a new add-on such as a slider, rotator, etc. can be added
This is the most common problem I encounter.
Wish you good work LFS Team
_ALP indicator overlay is not allowed.
Indicator overlay maximum size 512x512
If it is possible for it to work, we should be offered this option
INDICATOR TYPE / Analogue or Digital
A 3D cursor for the analogue display to which a new add-on such as a slider, rotator, etc. can be added
This is the most common problem I encounter.
Wish you good work LFS Team
So, will anything be added to the editor with the new update?
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 ]
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, .
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.
I saw you saying "Track editor: minor usability improvements" does this mean we will have access to the track editor? As a map modder for gmod, id love to make tracks for lfs as well, im looking forward to it
Technical progress report, March 2025
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.
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.
FGED GREDG RDFGDR GSFDG