Thanks for the report.

It looks as if that has been the case for a long time, I think since before LFS editor was released.

EDIT: Correction, it looks like the change was September/October 2022. I think the setup storage changes were related to multithreading. So it probably did work correctly in the earliest public versions of LFS Editor.

Without much investigation, I don't think it should be like that, but on the other hand I think it doesn't really affect anything much (given the current limitations of LFS suspension physics). I think it was an unintended result of a change around the way the live setup is stored. I'll have a look to see if it can be corrected.

Last edited by Scawen, Thu 5 Jun 2025, 07:32.

If it's not a particular mod (or some particular mods) then the only thing to do is wait for the big release of the new graphics version.

In the new version:

Only the "physics" part of the vehicle is created when the player leaves the pits. The graphical model is delayed, and only created (on the graphics thread) when that vehicle comes into view. There may still be a small glitch at that point, but it will be less than in the old (current) version because no textures are loaded at that point. The textures are loaded one at a time over the subsequent frames, instead of loading them all at once.

In short, pit-out glitch is a well known and 'ancient' problem that is worsened by some mods, and I've already dealt with it by various means, for this reason. Unfortunately you still have to wait a while before you get the updates.

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.

Hello LFS mods users.

We have allowed through review a few "track mods" which use an "object" mod to represent the scenery of a track.

A small central physics object (LOD2 or LOD3) is created and sits on the ground, while LOD1 represents the scenery. There was a problem with the scenery disappearing if the viewpoint was too far from the origin.

Mod creators were able to get around this by using a hacked LOD distance, but we don't want to allow such hacks. It's better to release a fix for the issue.

At the same time, I had a note on my list for the development version about a bad calculation for the view radius of some mod vehicles with subobjects (that has become a problem since the addition of moving subobjects).

Two of these track mods have been waiting to be published and it seemed a good idea to help them and solve the view radius problem at the same time.

Now, the distance from an object is calculated as the distance from the object's bounding sphere instead of the distance from the object centre, which solves the problem. It is impossible for a lower LOD to be selected if you are within the bounding sphere of LOD1.

If you would like to join a server that has a track mod, you should use the new test patch 0.7F7 (or later) available in the test patch forum:
https://www.lfs.net/forum/thread/110607

If you are developing a track mod you should use the new editor test patch 0.7F7 available in the mods forum:
https://www.lfs.net/forum/thread/111321

Future development possibilities:

The track mod support is not very good at this time. It is a bit obscure as a player needs to "drive" the track mod and it has to enter as a physics object and settle on the ground. Our mods system was obviously designed for vehicles only. It would be nice to properly support such objects in the future, for example:

1) A new object type "solid" or "track" which does not enter physics at all and cannot move
2) Increased number of collision triangles for unmovable objects
3) Place a track mod as a layout object instead of using a player slot and start position

Examples (1) and (2) look quite easy to add (in an incompatible version) while (3) is a lot more complicated.
There is no time to develop such features at the moment. I am just pointing out that there is a possible future for track mods that goes beyond this current minor improvement. Track mods might not have to be a whole track but could be a bridge, a podium, or some other type of stationary object.

Last edited by Scawen, Sat 10 May 2025, 17:16.

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

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

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

[ EDIT:

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

Three more points:

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

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

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

end of EDIT ]

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

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.

WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM

PLEASE TEST BEFORE YOU POST

PLEASE... NO OFF TOPIC FEATURE REQUESTS!


Hello Racers,

Here is a new test patch: 0.7F10

Please read the list of changes below.

0.7F10 is COMPATIBLE with 0.7F

- You CAN connect online with 0.7F
- You CAN play single player replays from 0.7F

You should back up or rename your LFS.exe from version F so you can revert to it if necessary.


Changes in F10:

List of Hosts now has 30 lines and does not show the obsolete status text
Hover text with description when the mouse cursor is above a blob in the IP column
FIX: Stopped on "Join Specific Host" page after "Start New Host" (should immediately join)


Changes in F9:

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


Changes in F8:

Forces view mode is no longer applied to object mods (e.g. track mods)
FIX: Fuel and damage settings were always default on non-route configs


Changes in F7:

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"


Changes in F6:

Force feedback:

Some steering wheels have a bug in their drivers, that cause them to seen as "First person controller" devices.
In this case, LFS does not know they are a steering wheel, so it does not enable the steering wheel bump stops.
There is a new option, in "Axes / FF" section to Enable steering wheel bump stops.
Do not use this if your controller is not a steering wheel.

VR:

It is possible for some VR headsets to have a FOV aspect ratio that is different from their pixel aspect ratio.
Until now, LFS did not deal with that case correctly, and this was apparent with the HTC Vive Pro 2.
Now, LFS uses the left, right, up, down FOV values more directly which should solve the problem.


Changes in F5:

InSim:

System to allow AI drivers to be directly controlled by a local InSim program.
Discussed here: https://www.lfs.net/forum/post/2114897#post2114897

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


INSTALLATION:

Live for Speed LFS 0.7F must already be installed!

- Rename your old LFS.exe
- Copy the LFS.exe from this patch zip into your LFS folder

NOTE: You can see if the patch is correctly installed when you run LFS.
Check the version number at the bottom of the entry screen.


DOWNLOAD:

IF YOU ALREADY HAVE 0.7F:
PATCH 0.7F TO 0.7F10 (ZIP)
https://www.lfs.net/file_lfs.p ... =LFS_PATCH_7F_TO_7F10.zip (1.2 MB)

Last edited by Scawen, Thu 26 Jun 2025, 18:39.

Right, first thing I had to do this morning was some essential maintenance (gutter clearing). The rain and hail brought more moss down.

I've had a bit of a fight with some php code but now the season signups are updated so admins of a league that is set to require approval of entries get a new email if:

1) There is a new entry
2) An entry that has been approved, is now edited

In case (2) the entry is no longer marked as 'approved'.

I've made it clearer to see on the admin pages if an entry requires approval.

I'll continue to look at more things now.


I know Viperakecske and some others will be frustrated that I'm not working on Tyre physics this afternoon but I'd really appreciate if they can keep out while I do a few more things this afternoon to make the league entry system good enough to be used for a high quality league. The idea will be to get on with the tyres in the morning. So please leave me in peace.

Well thank you very much and I hope I haven't been too annoying pressurising you to do it. I will look at some this morning and will keep supporting it as you go. For anyone concerned, this will not stop me working on the tyre physics this afternoon.

I understand it's an experiment and I thank you for making that experiment real.

EDIT: I'll do the country export of CSV as one of the first things and look at user-editing removing approved status, and sending an email to all admins when a change is made. Maybe, to avoid email spam, an email like that is only made, when an "approved" entry is edited and becomes no longer approved?

Last edited by Scawen, Mon 27 Jan 2025, 11:10.

Quote from Pukyy :

...as the updates that we find necessary are taking a longer time because of the focus on the cruise side of the game...

Total speculation and in fact complete rubbish.

People are free to suggest what they want and I will choose what I do and how to manage my time.

If other people will be deciding what I do I might as well go and get a job as a programmer and earn 5 times the salary.

I'd be grateful if community members wouldn't try to be self appointed LFS project managers.

I did one afternoon's work and a morning fixing it, on something that people have been waiting for, for longer than people have been waiting for tyre physics. This had no bearing at all on the completion of the tyre physics. Please avoid making up rubbish and allow people to make sensible suggestions if they wish to.

This is the LFS Programmer Forum.

In most cases it is probably best to not comment if you aren't a programmer. Otherwise I would have posted in General LFS Discussion or Test Patch forum.

I don't go and post my opinions in the quantum physics forums because I probably don't know what the **** I am talking about.

I don't want to get involved in a conversation but I'll say a few things then I'll unsubscribe from the thread.

Quote from Flame CZE :

I'm curious what progress Eric has made regarding the track updates and even the new tracks. Last report from him was in the 20th anniversary news article from 2022. Are the existing tracks fully updated now, or are there still some holes to fill? It would be nice to see some screenshots if there is something new to show.

I think Eric knows what I have been going through this year and probably didn't want to bother me with a progress report. And on the other hand he took on a pretty monumental task and so maybe he wanted it near complete before showing anything. I don't know really, I have not tried to discuss a progress report with him.

He did even more finishing of South City and has done repairs and updates on all the other tracks too. There's a curious thing about finishing things, as anyone knows who takes on big projects. The 'last few things' take a lot longer than expected.

But the biggest task he has been on for a long time, is Kyoto. Not only has the track had a lot of work done, but also the surrounding areas, it has had a treatment that could remind you of Westhill. I think he saw the potential and went for it. I'm sure you will be very happy to see a progress report about it when the time comes.

Quote from gu3st :

It also doesn't help that recently Scawen has needed to take more web development tasks on either. There's enough PHP knowledge in the community that I think a trusted group might be able to help directly or at least give some informed advice. I'm not really a PHP dev anymore (outside of some contract work on a popular livery sharing site), but I do have many many years of knowledge and expertise with web dev.

I just want to make it clear, I didn't start this year saying, "OK, now I will spend the first 7 months of the year doing web stuff that is out of my comfort zone". I didn't know at the start of the year that Victor would be more involved with his other job and gradually become more reluctant to work on Live for Speed.

The reality is I encountered a barrage of emergency situations (and growing problems) which needed attention. To list a few:

1) Mod hacks that were destroying the online experience
2) Mod submission spam that was overwhelming the reviewers
3) Bugs in mods system e.g. archives of deleted mods never being removed
4) Apparent leak of passwords that LFS users had given to a pirate website years ago
5) Bugs in hosting system causing crashes, slowdowns, etc.
6) DDoS attacks on web server
7) DDoS attacks on game servers

This is not a complete list, it's just off the top of my head. Each of these things took days or weeks to resolve, but at the start of each task I couldn't really delegate the task to community members. I just had to look into the issues and figure out what is going wrong, although the relevant systems were not written my me, and at the start of this year I really had no idea how it all worked. After figuring out the issue, either fix it (sometimes simple) or implement new systems as required (not usually simple).

I'm just explaining how one task after another has come my way, preventing me from doing whatever was planned, and this has sometimes been very frustrating, but it's not something that could be delegated to community members.

This new patch is intended to be a stable release. With all the fixes done, I hope that our systems may be stable for a while. This should let me focus on the tyre physics, to complete it to a good condition so it can possibly be released, along with some remaining graphical tasks. I can't give a time frame for this, as so far this year I've had almost no time to look into it. It seems like now I'm where I thought I would be at the start of January.

At least with all the delays on my side, Eric has had more time to do extra good work and keep up the detail. I have also learned a whole lot about PHP and SQL and understand how our web systems work. For example I was able to do this whole 0.7F update release alone without Victor's help.

Have you tried graphics options like:

Textures: low res
Texture filtering/AF: 1x

Misc options:

Full physics for remote cars: [no]

I think what you saw was down to 2 different things.

1) You saw damage on his car, but he did not. This could be that on your computer, damage was inflicted on his engine due to differences on your computer calculating the physics, compared with the 'real' case on his computer. Soon, some info came from his computer correcting the engine damage your computer had estimated too high.

2) Later, he and you had engine damage but the other could not see it. This could be due to granularity due to compressed data. Your engine health would have to be worse than 99.8% to be visible on a remote computer. But it only has to be worse than 99.95% to be visible on the local computer.

It's not because of the location of the object centre. That doesn't affect physics, but it does mean the setups are not interchangeable.

The editor cars have been updated to have realistic setups. I don't know the specifics, but maybe you could open two instances of LFS and look through side by side, to see what the changes are. That's the only way I would be able to tell you the changes.

If you replicated all the settings and confirm the wheel sizes have not changed then you should get the same handling. It's likely that rim width has decreased because most of the public LFS ones are unrealistic (long subject, watch the video if interested). But rim with in LFS doesn't affect much, probably just affects wheel heating a tiny amount over a long period.

Differences between current public version and versions set up for future release aren't something I will get involved in or take an interest in.

Thanks, I decided not to add that one as it is not available in the new physics version.

No, I'm not a perfectionist.

I just want to release something that will be fun and not containing extreme flaws that would destroy racing altogether. No, I will not expand on this comment. I need to spend some peaceful time focused on the tyre physics, to understand exactly what is good and bad about it.

I'd like to get back to the tyre physics so we can get something released, although LFS will never be finished or perfect.

Unfortunately I have not yet worked even one hour this year on the tyre physics as I've been dealing with mod stuff most of the time. There were too many holes in the system and people were exploiting every crack. I hope that is coming to an end now with various improvements.

The mods system is simultaneously the best and worst thing ever to have happened to LFS.

The idea is to release a new version hopefully in a week or two (just like the current test patch with a couple more updates) then I can get back to work on the new version. So basically at start of April I'll be in the position I wanted to be at start of January.

OK, I've done a fix for the replay slider + MCI disconnect issue in Test Patch E8.

Now, when clicking on replay slider or using IS_RIP to do the same thing, NLP/MCI packets will not be sent. I hope this works because I haven't actually tested it, but it was just a line of code.

In the case when using IS_RIP with option RIPOPT_FULL_PHYS the NLP/MCI packets are still sent. My hope is that because it is taking the time to do the physics, the rate of MCI output may be manageable. But I haven't tested this at all so I can't really confirm.


About the similar issue when joining a server, I couldn't think of a quick way to safely avoid sending the packets until LFS catches up with the server. I want to consider this a bit longer.

OK, I'll describe that but first I will mention that saving is only in the graphical render code, not the physics.

The thing about tyres is as they are flexible objects, their vertices cannot simply reside on the graphics card memory. They must be calculated every frame and the vertices are sent from the CPU to the GPU each time. I had thought before the main cost was actually transferring the vertices to the graphics card, and calculating the normals of each vertex. But what I found was the worst part was calculating the colour of each vertex (according to its lighting condition and the sun highlight). This used a lot of integer maths and I found the CPU use was way less when I bypassed this function, returning a simple grey colour. So I set about converting it to floating point maths.

The general idea is that integer maths is good for adding and subtracting, but floating point is better when there is a lot of multiplying involved. There's some leftover integer maths in LFS left over from earlier times. Considering some of its code goes back around 30 years, when we had 486 processors, I worked at Digital Integration on the Hind Helicopter Simulator, Pentium was the latest super CPU and there were no 3D cards.

By converting to floating point I found it was instantly faster, so I changed the code some more so that the normals were calculated in floating point, actually borrowing some code from the development version, where this was done already.

In the development version, the tyre lighting is actually done on the GPU, based on material properties, but the vertex normals are still sent to the graphics card each frame. You can see it in the LFS Editor.

The older code (before Friday) had a lot of complicated stuff to avoid sending vertices if they were not needed. This was done by checking if a triangle faced the user's view before drawing it, then calculating vertices as needed. But that is way complicated. It's better, if possible to just calculate all the vertices then send them all, without jumping around between triangle and vertex code. But for quite a while the "avoid sending unnecessary vertices" was still winning. But eventually I got the vertex normal and lighting calculations fast enough that it was better to do it the simpler way and I saw best results in the profiler that way.

Unfortunately that work, that took most of a day, doesn't benefit the development version because it was already done in that version. In the D3D11 version with shadow maps, all triangles must be sent every time as they may be seen in a shadow map (drawn from sun direction viewpoint). So it was impossible in that version to avoid drawing the away-facing triangles. But in the development version there is code to only send one object's triangles to the GPU once each frame, even if it will be used in multiple shadow maps, main view, mirrors and stereoscopic images in that single frame.

But although it doesn't help the development version, we still have the current public version for some months ongoing, so I'm happy if it helps people racing on full grids and the helps the quality of broadcasts by saving a few percent of CPU each frame.

Last edited by Scawen, Sun 11 Feb 2024, 21:05.

Quote from rane_nbg :

I see, tnx for explanation. How much is a hard limit for LOD3 then?

The limit for the physics LOD, whether it is in LOD2 or LOD3, has always been:
Vehicle: points 24 / triangles 42
Object: points 32 / triangles 60

Quote from Eclipsed :

That would start the 2nd wave of mods killing...

There's no mod killing, just a request for people to fix their hacks and help make a good racing / online experience. We don't want to host poorly made lazy mods on our system. There's no need for shoddy work.

Let's not pretend there's something good about people making LOD2 a duplicate of LOD1, or a pointless empty LOD2, or single wheels with more polygons than 9 Raceabouts, or LOD1 with an "export only - do not use" config with half the model deleted, only to cheat the limit.

Last edited by Scawen, Fri 2 Feb 2024, 21:14.

I hope so too. Some of the mods were seriously beyond any reason, I found one that had 65536 triangles per wheel and several with 32000 triangles per wheel.

For reference, the entire Raceabout model (excluding wheels) is 7288 triangles. So 4.5 times that for a single wheel is just silly.

Also quite a few people have abused the LOD system, for example by making LOD2 a straight copy of LOD1 which is really not the spirit, and makes the car take twice as long to generate.

It's pointless, as LOD2 is not actually a requirement. It's possible (and fine for WIP mods) to have only a main LOD and a physics LOD.

Another part of the pitout glitch that will not be fixed at this point, is texture loading. I've worked on that in thew new development version which I want to work on and release. Textures are loaded gradually over the coming frames instead of all at once. So I hope that mod creators will cooperate and do the right thing, so that I have more time available to work on actual development.

WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM

PLEASE TEST BEFORE YOU POST

PLEASE... NO OFF TOPIC FEATURE REQUESTS!


Hello Racers,

Here is a new test patch: 0.7E15

Please read the list of changes below.

0.7E15 is COMPATIBLE with 0.7E

- You CAN connect online with 0.7E
- You CAN play single player replays from 0.7E

You should back up or rename your LFS.exe from version E so you can revert to it if necessary.


Changes in E15:

Improved auto updater and available hosting locations
- New update available is shown on entry screen
- Auto updater page is clearer and simpler to use
- Hosting locations are downloaded instead of hard coded


Changes in E14:

Mark host as favourite and sort by favourites in list of hosts
Sort by server location (two-letter country code) column


Changes in E13:

Improved handling of UDP packets not reaching the host
- List of Hosts comes direct from master server (no pinging)
- You can connect even if host does not receive your UDP packets


Changes in E12:

Cameras:

Small change in calculation of free view camera smoothing
- only intended as preparation for a future change
- slightly more efficient calculation
- should provide identical motion

Multiplayer:

Support for new command to set number of stops completed

Commands:

FIX: Multiple commands now allow more than 1 space between commands

Translations:

More updated translations - Thank you translators!


Changes in E11:

Cameras:

Layout Square cameras now have 40m height instead of 4m
Reduced jiggling of names above cars at extreme zoom
Improved accuracy of camera rotation at extreme zoom

Commands:

/vlock=car/filter/horizon
/lookf=joystick/axis/steer/mouse_x/mouse_xy
/control=mouse_kb/wheel_js


Changes in E10:

FIX: Invert mouse axis did not work in E9


Changes in E9:

Input range improvements:

The full resolution reported by the controller is now supported
- previously drivers were instructed to report -1000 to 1000
- controllers we tested report values 0 to 65535
- so steering wheel moves in smaller steps
The range adjusters in controller options now use percentage values
- the range defaults replicate previously default in-game behaviour
- previously brake/throttle/handbrake/clutch axes had a dead zone
- the dead zones were not adjustable by the user but now are
- the axes visible in game now match the options screen

Support for mod approval:

WIP filter is available on the mod selection screen

Translations:

More translations updated! Thanks to the translators


Changes in E8:

Support for approved mods:

Tick (aka check mark) is shown in mods screen for approved mods
- also TW is shown for tweak mods and padlock for private mods
An 'external link icon' is visible when two columns are displayed
Rating stars pulsate in garage if you have not yet rated the mod

InSim:

NLP/MCI packets are no longer sent after clicking replay slider
- also not sent after IS_RIP unless RIPOPT_FULL_PHYS is set


Changes in E7:

Tightened main model and wheel limits for mod reports
Unlock screen requires "unlock" to keep any changes
(if already unlocked the unlock count is unaffected)
More translation updates. Thank you translators!


Changes in E6:

Optimisations:

Combine rim and spoke object into a single subobject
- saves 4 extra subobject switches for most cars
- update also applies to development version
An optimisation specially for external views
- avoid begin/end scene when drawing env maps/shadows
Tiny opt when drawing driver (avoid some integer maths)
Tiny opt (set projection matrix only once per frame)

Icon:

Fixed icon (old one was copied by mistake in E5 patch)

Translations:

More translation updates, thanks to translators!


Changes in E5:

Mods screen:

New button to show your own mods
Ability to switch on multiple vehicle type filters
New filters for drive type (none/RWD/FWD/AWD)
New sort options power/mass/power-weight ratio
X button beside text filters stops text entry
Updated translations - thanks to translators

Optimisations:

Decreased CPU used when drawing tyres
- reduces CPU used by official GTR cars by around 7%
- smaller optimisation for suspension parts


Changes in E4:

Prevents frequent excess reports for the same mod


Changes in E3:

LOD2 limit detections:

Use true limit of 8192 (which is excessive even if legal)
- LOD2 should really be nearer 1000 triangles (see official cars)
- The check in E2 was extra lenient (as it still is for wheels)
Added check for invisible LOD2 (there is no need for bad LOD2)
- Thread about LOD2: https://www.lfs.net/forum/thread/106736


Changes in E2:

Automatic reporting system for mods with excessive triangles
New command /rtex does a full texture reload from any screen
Some updated translations - thank you translators!

FIX: New steer animation for BF1 stops driver toes protruding
FIX: Minor documentation errors in InSim.txt


INSTALLATION:

Live for Speed LFS 0.7E must already be installed!

To install the patch, download and run the patch installer.

NOTE: You can see if the patch is correctly installed when you run
LFS. Check the version number at the bottom of the entry screen.


DOWNLOAD:

IF YOU ALREADY HAVE 0.7E:
PATCH 0.7E TO 0.7E15 (INSTALLER)
https://www.lfs.net/file_lfs.p ... ATCH_7E_TO_7E15_setup.exe (1.8 MB)

Last edited by Scawen, Wed 3 Jul 2024, 17:40.

I've added that to the RB4, and fixed the triangle errors in XRR / FO8 / XFR / FOX.

I'm nearly at the point to send Eric an update, and I've coded a setup height repair system as these development models have the model object centre correctly located at the lowest point of the model, instead of at rough ground level or whatever other random position they were in the old versions. The repair detects old setup and adjusts height according to a table of height adjustments for the official cars.

That's so all the existing setups will load correctly in the new version. No doubt they'll need an adjustment for the new physics but I think there's no harm in working from old setups.

I think you mean: multiple, selectable wheel styles in a single vehicle.

It's something I'd like to do eventually but it's a big job, cannot be done in a compatible version.

As I keep saying, I'm working on the development version now, not mods (which I've been working on for two years already).


EDIT: OK, apparently I'm losing track of time. Here's a rough history.

We have been working on the new graphics and physics versions for years.
2021 I spent most of the year on mods which we released that year.
2022 was a bit more on mods then back to graphics, multithreading, etc.
2023 I seemed to get pulled back onto mods for most of the year.

The end of 2023 was an unforgettable extreme push on mods so it would be much appreciated if people wouldn't keep asking for big changes to the mods system right now. I can do a few updates here and there to the editor. But my main focus is the new development version.

Last edited by Scawen, Fri 19 Jan 2024, 09:59.

While giving due respect for the pretty mod, it does have a lot of triangles (maxed out in one config and slightly over in the other config) and the wheels exceed the limit.

It's almost exactly the same story as for the N.400S here: https://www.lfs.net/forum/post/2074548#post2074548

Wheels could be made more efficient by using the new rim editor, anyway all the info is in that thread.


EDIT: But I don't believe that making the wheels legal would really sort out the glitch. It should be done, and the new rim editor should be used, and that would help a bit, but I think the maximum number of polygons for the main body is really too high for most computers. Personally I would go for half of the maximum, but I know not many people will agree with me. The RB4 is 2/3 of the maximum.

Another thing on this model, a problem that N.400S does not have - the middle LOD is way too high at 8104 triangles. The maximum is 8192 triangles but middle LODs should really be less than 1000 in my opinion.

One thing I hope is that you will find the pit out glitch is reduced in the new physics and graphics version. I have worked on it. Some of it is spread over more than one frame, especially if you aren't looking at the car at the time. The physical model is built in a physical frame and the graphical model is built when necessary in a graphical frame. Also, in the case of a car that hasn't yet been loaded, and is then loaded the first time since starting LFS, the textures are loaded over multiple frames so that worst of all "first time load" glitch is further reduced.

Last edited by Scawen, Tue 16 Jan 2024, 20:34.