Could be someone leaving the pits with a skin or mod you dont have downloaded yet. Game freezes for a moment when downloading mods and skins. Moving to NVMe could help this due to improved read/write speeds over traditional spinny drive.
Yes, please look at the chat log when a freeze happens. It would be good to know if it is when someone leaves the pits and if that is the cause it would be interesting to know which car they are using, that causes a significant glitch. And about how long are these freezes you see? Some makers of low quality mods found a loophole that allowed them to upload mods with an excessive number of polygons (I've seen a mod with 3 times the legal number).
This loophole has now been closed for mods when they are updated, but existing mods may still have this issue. If you find particular bad ones we could disable their use online.
This happened today at the 324th Rony's Tuesday Fun Race - 2024 Season 1 Round 1 | Live for Speed. In practice there were also minor problems coming out of the pits.
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.
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.
@Scawen I suppose the freezes occur while the game is loading the assets (car model and/or skin), would it be possible to load those on a non-blocking thread instead? And either keep the car invisible while assets are still loading, or load and display them from lowest LOD to highest, so that the game could still display something while it loads the higher detailed stuff, and avoid stuttering/freezing?
I know you don't agree with many modders about triangle count, and I understand the reasoning, though I don't personally agree that 65k triangles is *too much* - however I do agree that getting 65k for the sake of getting them, even if they don't bring anything visually, is a waste of resources. I just think that some other popular sims (think iRacing or ACC) manage grids larger than LFS, with cars that I believe are probably all more detailed than LFS cars (and probably LFS mods as well), and they seem to work pretty well; the engine running the games is different though (Unreal for ACC, not sure about iRacing), so while I agree modders should not abuse the limits, and I understand why you don't want to increase those limits, maybe there is still something you could do to alleviate this particular issue?
I'm not sure what the threshold is where the problem appears, I know some people talked about it after the NDR GT4 Sprint Cup with the N.400S GT4 (there were 35 cars racing + safety car and rescue vehicles), I didn't personally notice any stuttering but I do have a rather powerful computer (Ryzen 7900X, AMD 7900XT, 32GB of RAM, NVMe SSD).
By the way yes, I remember that even before the mod system there was a common problem that people have lag when others leaving the pit. So mods were obviously not involved because they did not exist yet.
This does not concern me at the moment as I have a relatively new computer and I have no lags.
We were rendering 40 x Maximum (and as Scawen eluded to, over-maximum) cars with an NVidia T4 GPU and look at what that did to the frame rate. The collision mesh of this mod is also extremely detailed and LFS was never designed to cope with that level of detail, especially with such a huge pile-up.
This is the first time we've experienced this level of lock-up in 351 broadcasts, and there's very little anyone (except mod creators) can do to improve the performance. Game engines like UE5 would struggle with this problem. The mod is just far too detailed.
That's because LFS is currently single-threaded. LFS normally waits until you're stationary before loading a skin to avoid issues associated with loading the texture. Hopefully loading cars/skins gets moved to another thread in the proposed multi-threading update.
100% agree. Could that be enforced somehow in the editor?
We (Sim Broadcasts) also noticed some frame drops during our broadcast of round 1 last Sunday. We'll be trialling a new AMD CPU with a 50% higher clock speed for round 2 to try and combat this (3 cheers for AWS ) - Your experience would have been smoother than ours because you were driving, not observing 35 cars at full LOD all at once.
There is indeed a specific problem with crashes of high res mods because of the deformation.
The mesh must be deformed which takes double the CPU if there are double the number of vertices. Then the updated mesh must be downloaded to the GPU which takes CPU time again, also in proportion with mesh detail.
One damage incident of a high res mesh is enough to cause a tiny glitch which may be imperceptible on a fast computer, but when there are several crashes going on it adds up and I would suppose this was the problem at that nasty Turn 1 incident.
It's actually a fairly new limit. Some lazy modders in the past used to copy the entire LOD1 to LOD2.
The high resolution LOD2 will take CPU time every frame. Just before drawing the car shadows it needs to run through the mesh to calculate the shadow boundaries.
It would be simple in code to enforce a new LOD2 limit but it might not be very welcome, so I'm not sure how to approach it. I think I would first have to do more research, to find out the actual CPU usage as this is really just theory if not tested.
It is possible to create an option in the game to load lod2 from a certain distance? Or, for example, the option that only 15 cars (can choose how many) closest to the camera can have lod1? For mods that have good quality lod2 and not too many triangles, this should help.
I can assure you my experience was not that smooth as my game actually *crashed* on both occasions (that's why I dropped out and had to start both races from the pitlane), though that was due to my Linux/wine not being properly configured and should not happen next Sunday (I hope, I'm not planning to install Windows ever again on my PC...).
The T1 incident with the Ferrari mod looks horrendous though, I've never seen such frame drops (or such T1 carnage ), it's definitely necessary to have sensible limits to avoid this kind of situation.