Would the (relatively) low poly count of default cars look worse with the new graphics, with the triangles being more visible?
Given that people are buying 120 / 144 / 240 / 360 FPS monitors now, being able to use the snapshot from the previous millisecond for the current frame view should massively increase the feel of the car. It's 10 times the workload tho, so I have to ask, how long does a physics calculation take per car? Having to do all of the physics updates within 1 millisecond seems like a huge ask even for current gen CPUs.
Good question but the answer is quite unknown at the moment.
In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.
In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.
But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.
Diagram:
Current:
0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]
Proposed:
0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]
I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.
I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.
The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times
Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times.
But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.
In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.
In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.
But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.
Diagram:
Current:
0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]
Proposed:
0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]
I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.
I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.
The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times
Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times.
But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.I do remember you saying that the physics happened at a higher rate, in another post a while back. I didn't realize the relation to cache hits in L1, L2, L3; That makes so much sense but not something that I had really thought about. I do wonder if the AMD 3D V-Cache would make a massive difference here. Just from looking at how the InSim packets are designed that memory alignment and structure packing is really a priority for you. How big is the Struct that contains the cars state? In the event that 64 cars are used, even if you are also running instructions from the cache, a modern CPU might still be able to fit all of that into its L1?
Could you search case insensitive for the whole word `/turn/`?
Could you search case insensitive for the whole word `/turn/`?
I think the new graphics were dx11, so most people should be fine. My laptop is slightly worse in the multi core test, but better in the single core (which is better for lfs). So I guess we will see how they perform in the new update. I will for sure report how it performs.
Any idea of what the new minimum specs could be?
intel pantium IV of course
That will probably change over time, as the game could be optimised more over time. At the start it might be more intensive, as it probably will be less optimised.
I read everything in this topic, and realized that I did not understand anything at all. But I realized that it is insanely difficult. I ask myself when these tasks will be completed and the time will come for a release with added tracks and a track editor. The new graphics are interesting. I would just like to wait for the update and the track editor, with the ability to create sand and gravel.
Thank you for the opportunity to create machines.
Good luck and fast problem solving!
Thank you for the opportunity to create machines.
Good luck and fast problem solving!
Yeah, definitely! As a programmer I love seeing these kind of posts from him.
I made a step forward in tyre physics last week. Although there is still a lot to do, I thought it would be good to try a test of the 1000Hz updates this week (nothing to do with tyre physics but may help with separating physics and graphics onto separate threads, along with other advantages). I was able to get a first version running in a day and worked another day searching through references to 'turns' and fixing various issues where the code had assumed that each turn was 0.01s. Now it's coded in a flexible way so I can change the update rate and recompile, to get comparisons between the 100Hz and 1000Hz versions. Actually there's a bit more searching to do but I was able to run some tests.
The good results:
The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...
This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.
That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.
With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.
Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.
Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.
The bad results:
So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.
Results when changing from 100Hz to 1000Hz:
10 cars on grid at new South City, physics code % of CPU time
environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40
What next:
The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.
The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.
The good results:
The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...
This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.
That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.
With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.
Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.
Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.
The bad results:
So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.
Results when changing from 100Hz to 1000Hz:
10 cars on grid at new South City, physics code % of CPU time
environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40
What next:
The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.
The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.
interesting 
Tnx Sawen for your work and progress report on gfx/physics. Might be worth thinking about some number for the gfx update rate which is an integer multiple of the refresh rate, like for example 120Hz. Would be beter for 60, 90, 120 and 240Hz screens. Then subupdates at 8×, giving 960Hz.
About optimizing environment checks, one approach that comes to my mind is to create at least 3 spacial zones around each important car propertiy. Each zone would have an increasing update rate checks, as the radius reduces. This way, one could save some CPU time, by avoiding unecessary checks that would not lead to collision.
About optimizing environment checks, one approach that comes to my mind is to create at least 3 spacial zones around each important car propertiy. Each zone would have an increasing update rate checks, as the radius reduces. This way, one could save some CPU time, by avoiding unecessary checks that would not lead to collision.
Thanks for the update!
I remember I implemented a simple collision check for air traffic controller sim (which was in JavaScript, and slow). Checking if point (plane) was in polygon (elevation at its level) at every tick was slowing things down noteable.
I tried adding a bounding box check before polygon, but that didn't help much with complex terrain, where many planes were always in some bounding boxes.
So I made a simpler check: initially, I calculated the distance to the closest terrain at plane's level. Then every tick I subtracted the travelled distance. If the remaining dist was below zero, then point in poly check ran, and distance too, again.
In the end, I used this distance subtraction approach + bounding box check + point in polygon check. (Recently I learned that point in poly can be simplified by cutting polygons in halfs vertically or horizontally, so point counts are reduced a lot.)
I remember I implemented a simple collision check for air traffic controller sim (which was in JavaScript, and slow). Checking if point (plane) was in polygon (elevation at its level) at every tick was slowing things down noteable.
I tried adding a bounding box check before polygon, but that didn't help much with complex terrain, where many planes were always in some bounding boxes.
So I made a simpler check: initially, I calculated the distance to the closest terrain at plane's level. Then every tick I subtracted the travelled distance. If the remaining dist was below zero, then point in poly check ran, and distance too, again.
In the end, I used this distance subtraction approach + bounding box check + point in polygon check. (Recently I learned that point in poly can be simplified by cutting polygons in halfs vertically or horizontally, so point counts are reduced a lot.)
Interesting progress. Not an easy task but smoothness could reach perfection if not saturating the cpu.
I was thinking the same, but why not consider also 480Hz? It would be almost 5x better overall than now but 2x less CPU intensive than 1000Hz, besides the optimisations Scawen has to do anyway.
If, as Scawen says, the physics update rate can be changed now using a single variable, could it be possible to set this value based on the specific computer power? The more power the more updates, the less power the less updates, so everybody is happy.
If not everyone has the same sync rate it will be out of sync party...
Does the new tyre physics have more realistic grip reaction to heat? The current ones make driving on overheated tyres feel like driving on ice track. It's the only big setback physics wise i've came across in LFS.
Seems like i have to upgrade my PC. I doubt my old R9 380 and FX8320 are able to run the new LFS in VR.
Everyone would have different physics and I'm sure someone would figure out the "optimal" rate and find a way to throttle LFS process to hit that rate.
1000 Hz is better to track lap times up to 3 decimal places without having to interpolate between two updates.
How does LFS do collision detection? Is there an acceleration structure, or is all geometry within overlapping grid cells checked or smth? Also, is SIMD used? Practically every CPU supports SSE2 nowadays, even later Windows 7 updates require it. I have a lot of experience in ray tracing acceleration and would love to have a peek at the collision detection code, though of course that's likely not possible.
No need for laptimes in carmeet cruise.
I agree whit you
Racing in LFS is slowly fading away,and it is sad to see,but its what its when mod update is more important than graphics and others.
mod update was more important at that time ! It brings new people to the party (and so some funds for the devs), while the graphical update may not bring that much in the end !
Anyway, you read it : Scawen is on topic with tire physics, and the graphical update is very advanced => so we can expect things to move forward 'soon'
.
We just wait for Eric to spam us with some Fern Bay 2.0 teasing screenshots
Anyway, you read it : Scawen is on topic with tire physics, and the graphical update is very advanced => so we can expect things to move forward 'soon'
. We just wait for Eric to spam us with some Fern Bay 2.0 teasing screenshots
This thread is closed
Graphics update progress @Scawen
(69 posts, closed, started )
FGED GREDG RDFGDR GSFDG